Second-to-last stop on the OSI tour: layer 6, the presentation layer. Layers 1 through 5 have managed to get the data there whole, in order, to the right process and inside a living dialogue — but nobody has yet asked something essential: what do those bytes mean? The very same byte stream could be text in one encoding or another, a JSON document, an image, compressed data or encrypted gibberish. The presentation layer is the one OSI dedicates to data representation: guaranteeing that what one end emits is exactly what the other understands, even if their systems differ inside. Like the session layer, it doesn't exist today as a separate piece — it lives inside applications and their libraries — but its problems are among the most frequent you will see: the ñ turned into ñ in a file, an API that doesn't understand the format it received, a certificate that won't validate. All of them are, conceptually, layer 6 incidents.

1. The presentation layer's role within the model
2. Character encoding: from ASCII to UTF-8 (and broken accents)
3. Formats and serialization: JSON and XML
4. Compression
5. Encryption: TLS seen through OSI
6. Why layer 6 lives inside the applications

The underlying problem is that the two ends of a communication may represent data internally in different ways: different operating systems, different programming languages, different conventions for text, numbers or dates. If each sent its data "just as it sits in memory", the other would read garbage.

The solution OSI formalizes: agree on a common representation for transit. The sender translates from its internal format to the common one; the receiver, from the common one to its own. That double translation is the essence of layer 6:

• What it receives from above (layer 7): data that is meaningful to the application (text, structures, images).
• What service it offers: a transit representation both ends can understand — which implies three families of services: format translation (encodings, serialization), compression and encryption.
• What it uses from below (layer 5): the established dialogue through which the already-represented bytes flow.
• Its PDU: data.

An analogy: two companies, one Spanish and one Japanese, negotiate a contract. Each thinks and files in its own language (internal format), but the contract is drafted in English (common transit representation), perhaps sent in a wax-sealed envelope (encryption) and in a summarized version for the registered fax (compression). Both sides' translators are the presentation layer.

The oldest and still the most frequent example of a representation problem is text. Deep down, only numbers (bytes) travel across the network, so an agreement is needed on which number represents which character:

• ASCII (1960s): 128 characters — the English alphabet without accents, digits and basic symbols. A is 65, a is 97. Enough for English; useless for "informática" or "Bilbao añade".
• Decades of regional patches: 256-character tables where codes 128-255 meant different things depending on the country (the Western European "latin-1"/Windows-1252 included Spanish accents and the ñ). Two systems with different tables = corrupted text.
• UTF-8 (the current standard): an encoding of the universal Unicode catalog, capable of representing any character in any language. Its stroke of genius: the first 128 characters match ASCII byte for byte (full backward compatibility), and the rest use 2, 3 or 4 bytes. Today it is the de facto encoding of the web and of nearly everything.

Symptom: Jon exports a file called clientes.csv from an old application in Bilbao and drops it on the file server. Marta opens it in Valencia and sees this:

Layer 6 diagnosis: the file arrived perfect — not one bit altered; layers 1-5 impeccable (the network copy and the file server bear no blame whatsoever). The problem is one of interpretation: the ñ in "Begoña" was saved in UTF-8, which represents it with two bytes (0xC3 0xB1). Marta's program assumed the file used the old one-byte-per-character table, and interpreted each byte separately: 0xC3 is Ã and 0xB1 is ± in that table. Result: every accented letter turns into two strange characters. (The reverse phenomenon exists too: a file saved in the old table and read as UTF-8 shows � or throws errors.)

The error's signature: one accented character → two odd symbols starting with Ã almost always betrays "UTF-8 read as latin-1". Solution: there is no "network to repair" and no file to fix — you open it specifying the correct encoding (editors and spreadsheets let you choose it on import), and going forward, agree on UTF-8 at both ends: export in UTF-8 from the Bilbao application. It is the canonical layer 6 solution: agree on the common representation.

One rung above characters sits structure. Applications handle organized data (a client with a name, city and phone number; a list of orders), but only byte sequences travel across the network. Serializing is converting an in-memory structure into a transmittable byte sequence; deserializing, rebuilding the structure at the other end. It is pure representation translation: textbook layer 6.

The two most common text formats you will see:

Both coexist at Meridiano: the modern intranet exposes its data as JSON (when Marta's browser requests the project list, it receives JSON and turns it into the table she sees), while the invoicing exchange with a large client uses XML because the client's veteran system demands it. And note that both are text, so the previous section still applies: a JSON containing "Begoña" also needs its agreed encoding (by convention, JSON is UTF-8 — a layer 6 decision made by the standard to remove the ambiguity).

Binary serialization formats also exist (more compact and faster, not readable at a glance), common between high-performance internal services; it is enough to know they exist and that they answer the same problem.

Third service: representing the same thing with fewer bytes. Compression exploits redundancies in the data (repetitive text, patterns) to shrink it before transmission, and is undone at the destination. Two professional nuances:

• Lossless vs lossy: lossless compression (that of a compressed file, or the one web servers apply to HTML) restores the exact original. Lossy compression (JPEG, the video call's audio/video) sacrifices imperceptible detail in exchange for enormous reductions — that is why a video call fits through Meridiano's VPN.
• Compressing what is already compressed achieves nothing (and can even make the result bigger): compressed data no longer has redundancy to exploit. That is why Meridiano's nightly backup gains nothing by recompressing the JPEG photos in the commercial archive.

An invisible everyday example: when Marta's browser requests the intranet, it announces which compressions it understands, and the server responds with the HTML compressed; the browser decompresses it without anyone noticing. Sender and receiver negotiate the representation — once again, layer 6's central pattern.

The fourth service carries the most weight today: encryption, transforming data so only the legitimate recipient can interpret it. Seen through OSI, encrypting is also a change of representation: the same data, in a form unreadable to third parties — the most radical of layer 6's translations.

You already know TLS from 02-05 as "the S in HTTPS", and in the previous lesson you saw its session-side face. Let's now complete its OSI file card, because TLS is the perfect example of why layers 5-7 merge in practice — a single protocol rendering services of two layers:

And riding on top of it travels HTTP, which is layer 7. When Marta opens https://intranet.grupomeridiano.example, her browser's real "stack" is HTTP over TLS over TCP: three pieces of software covering layers 7-6-5-4 with no respect for the theoretical borders. The OSI model doesn't describe how TLS is built; it describes which functions it performs — and that is enough to reason with: if the problem is "invalid certificate", it is the establishment/identity facet (5-6); if it is "the data arrives but comes out corrupted after decrypting", it is representation (6); if it is "error 500", it is the application (7). The data, mind you, is encrypted before descending to layer 4: the routers, the VPN and any snooper on the network see only opaque bytes — the encrypted representation crosses the lower layers intact.

As with the session layer, the final question: why is there no operating system "presentation service"? The answer is the same story with a different protagonist: each application needs different representations, and it proved more practical to solve it with libraries that each program incorporates than with one universal layer:

• Text is handled by each language's encoding libraries (they all know how to read and write UTF-8).
• Serialization, by each environment's JSON/XML libraries.
• Compression, by standard libraries that browsers and servers integrate.
• Encryption, by TLS libraries used by browsers, servers and almost everything that speaks over the network.

For a developer — perhaps your case — this has a very direct reading: when you choose a file's encoding, define an API's JSON or configure TLS, you are working at layer 6, even though no framework manual calls it that. And for diagnosis, the now-familiar consequence: presentation problems (broken accents, "unexpected format", certificate failures) happen with the network in perfect health — no layer 1-4 tool will see them, because the bytes arrive impeccable; what's broken is the agreement about their meaning.

• Blaming the network (or the file) for broken accents. If ñ shows up where an ñ belonged, the bytes arrived perfect: it is an encoding disagreement between whoever wrote and whoever reads. It gets fixed by choosing the right encoding when opening, and prevented by standardizing on UTF-8.
• Believing UTF-8 always uses one byte per character. ASCII characters do; accents and ñ use two bytes. Half of all encoding bugs are born of code that assumes "1 character = 1 byte".
• Thinking encryption is "a network layer thing" because it protects the communication. Conceptually it is a representation service (layer 6): it transforms data at the endpoints; layers 1-4 carry opaque bytes without knowing they are encrypted. (Meridiano's VPN encrypts at the packet level, further down — a different mechanism for a different goal; the intranet's TLS is the layer 6 one.)
• Trying to fit TLS into a single OSI layer. It doesn't fit, and that's fine: it renders session (5) and presentation (6) services over transport (4). The model exists to name its functions, not to classify the whole protocol.
• Tip: standardize on UTF-8 in everything you touch (files, databases, exports) and always declare the encoding explicitly wherever the format allows it. 90% of text problems vanish with that single policy.
• Tip: faced with data "arriving wrong", first ask: are the bytes arriving wrong (layers 1-4: rare, and retransmissions would give it away) or is their interpretation arriving wrong (layer 6: encoding, format, decryption)? The answer is almost always the latter.

Exercise 1. Classify each item into its layer 6 service (character encoding, serialization, compression, encryption) — or state that it is not layer 6: (a) the intranet returns the project list as JSON; (b) the server sends the HTML compressed to Ana's browser; (c) the HTTPS padlock on the intranet; (d) Jon's file that Marta sees with ñ; (e) the TTL that the VPN's routers decrement.

Exercise 2. Marta opens clientes.csv and sees Begoña instead of Begoña. (a) Explain what happened at the byte level (the file is in UTF-8 and her program reads it as the old one-byte table). (b) Why can you assert that the network and the file server bear no blame? (c) State the immediate fix and the preventive one.

Exercise 3. Meridiano's intranet exposes data as JSON to a small desktop application used by the administration team. After a server update, the application fails with "invalid response format", even though the browser displays the intranet perfectly and the ping, DNS and certificate are all impeccable. (a) At which conceptual layer do you place the problem, and what do you rule out with the given facts? (b) Propose two plausible causes consistent with "the browser works but the application doesn't".

Solution 1. (a) Serialization (structure → JSON text). (b) Compression (same information, fewer bytes, negotiated between browser and server). (c) Encryption (TLS in its layer 6 facet; the establishment/identity part additionally has a layer 5 facet). (d) Character encoding (UTF-8 vs old-table disagreement). (e) Not layer 6: the TTL is layer 3 (network).

Solution 2. (a) The ñ was written in UTF-8 as two bytes (0xC3 0xB1). Marta's program, assuming one byte per character, translated each byte separately with the old table: 0xC3→Ã, 0xB1→±, and displayed ñ. Every non-ASCII character in the file suffers the same doubling. (b) Because the received bytes are identical to the sent ones — had the network corrupted data, layer 2 would have discarded the frames (FCS) and TCP would have retransmitted; besides, the error is systematic (every accent, always the same way), which betrays interpretation, not random corruption. (c) Immediate: reopen/import the file specifying UTF-8. Preventive: agree on UTF-8 at both ends — have the Bilbao application export in UTF-8 (or declare the encoding as part of the exchange process).

Solution 3. (a) Layer 6 (representation/serialization): layers 1-4 are ruled out by the ping and by the fact that a response arrives; the DNS and the certificate rule out resolution and the secure establishment; and the browser working indicates the service (layer 7) responds. What fails is the format agreement between the updated server and the desktop application. (b) Plausible causes: the update changed the JSON's structure (fields renamed, moved or removed) and the application deserializes against the old schema — the browser doesn't suffer it because the web frontend was updated at the same time; or the server changed some aspect of the representation that the browser tolerates and the application doesn't (e.g., it now responds compressed by default, or the content's encoding/declaration changed, and the application neither negotiates nor handles it). In both cases, the fix lives in the software and its data contract, not in the network.

The presentation layer is the guardian of meaning: where layers 1-5 guarantee the bytes arrive, layer 6 guarantees they are interpreted the same at both ends. Its four services will accompany you daily: character encoding (ASCII → UTF-8, with the unmistakable ñ signature when the agreement breaks), serialization (JSON and XML as common representations of structures), compression (the same thing in fewer bytes, negotiated, with the caveat about already-compressed data) and encryption (TLS as a radical change of representation, straddling layers 5 and 6). And the takeaway shared with the session layer: this layer lives in applications and their libraries, so its breakdowns show up with the network in perfect condition. Only one rung remains: the point where the network finally touches the programs and the people using them — what it means exactly for HTTP or DNS to "be layer 7", and how the complete model looks from the top. The application layer closes the tour in the next lesson.