EMZETT.OSI Layer: Application
In short: The top (7th) layer of the OSI model — this is where the protocols run with which applications communicate directly, e.g. HTTP, SMTP, SSH.
In more detail: For users and application developers the “most visible” layer, because this is where the actual, purpose-specific communication takes place (requesting a web page, sending an email). All layers below (presentation, session, transport, network, data link, physical) are transparent to the application — it doesn’t have to deal with details such as routing or bit transmission.
In Depth
Protocols, not programs
The application layer does NOT contain the end-user applications themselves (i.e. not the browser or the email program as software), but the protocols through which such applications communicate. A web browser “speaks” HTTP/HTTPS, a mail client SMTP (for sending) and IMAP/POP3 (for retrieving), a terminal program SSH, a file transfer tool FTP or SFTP — each of these protocols defines its own “language” suited to its particular use case (specific commands, specific response formats). This variety is deliberate: a protocol for file uploads needs different mechanisms (e.g. resuming interrupted transfers) than one for short, interactive web requests.
Security plays out here
This layer is also where most of the security decisions visible to end users play out: HTTPS (HTTP over TLS) encrypts at exactly this level, by embedding the encryption function actually assigned to the presentation layer directly into the application communication — one reason why the classic separation into 7 layers often blurs in practice (see OSI layer: presentation). Authentication (logins, API keys, OAuth tokens) also takes place at the application level, not at lower layers that know nothing about the purpose-specific meaning of the transmitted data.
Diagnosis: where exactly is the problem?
If a web page doesn’t load, but a ping to the server succeeds (so layer 3 works) and even a TCP connection to the right port can be established (so layer 4 works too), this points specifically to a problem at the application level — e.g. the web server process itself isn’t running, returns an internal error, or the requested application protocol is being spoken incorrectly. This narrowing down “from bottom to top” (first check cable/signal, then routing, then the connection, and only last the application itself) is a standard approach in systematic troubleshooting in networks, because it prevents wasting time on complex application debugging when actually a cable is already loose.
See also: OSI model, OSI layer: presentation