PDF 2.0 Errata 3: What a Real PDF Actually Means

TL;DR

On June 18, 2026 the PDF Association released PDF 2.0 Errata Collection 3 (EC3) — a complete replacement for EC2 that folds 356 errata into 766 edits against ISO 32000-2:2020, now 86% ISO-approved (up from 54% in EC2), and bundles updated versions of ISO/TS 32001:2022 and ISO/TS 32002:2022. Roughly eleven people outside the PDF Association will read it cover to cover. But it's the clearest possible reminder of something most "PDF converters" quietly depend on you not knowing: PDF is a specification, not a picture. A file isn't a real PDF because it ends in .pdf and opens in a viewer. It's a real PDF because it carries text objects, embedded font programs, and link annotations that mean something. Convert: Anything to PDF produces real PDFs — and it does that for an unglamorous reason: we didn't write the PDF writer. Web pages go through Chrome's own print engine; files go through jsPDF. That's a deliberate decision, and it comes with a ceiling we'll name plainly below.

What actually shipped on June 18, 2026

Here's the whole news item, stripped of ceremony.

The PDF Association published Errata Collection 3 for PDF 2.0. It completely replaces EC2 — you don't stack them, you swap them. It gathers 356 errata, which cash out to 766 individual edits against the text of ISO 32000-2:2020, the current PDF 2.0 standard. 86% of those errata now carry ISO approval, up from 54% in the previous collection. It also bundles updated copies of ISO/TS 32001:2022 and ISO/TS 32002:2022, two Technical Specifications that travel alongside the core standard.

That's it. No new features. No press cycle. No launch video.

We won't pretend to summarize what's inside those 766 edits, because we haven't read all 766 and neither has anyone selling you a PDF tool. What matters is the shape of the news: the PDF specification is a living document that gets corrected. People find ambiguities and outright mistakes in a thousand-page ISO standard, they file them, a committee argues, and the text gets fixed. The jump from 54% to 86% approved is the boring machinery of a standard getting more precise over time.

What an errata collection is, in plain English

Imagine a very long instruction manual for building a machine. Thousands of people build the machine from it, and inevitably some of them find that one paragraph says one thing and a table three chapters later implies another — or that a sentence is ambiguous in a way that lets two implementers make incompatible choices, both "correct" per the text.

An errata collection is the list of those problems plus the agreed fix for each. It's not a new version of the machine. It's the manual, corrected.

Why care? Because the "PDF" you get out of a tool is only as good as that tool's reading of the manual. And a huge number of tools in this space don't read the manual at all. They take a picture.

PDF is a specification, not a picture

This is the spine of the whole post, so let's be blunt about it.

There are two completely different things that both end in .pdf and both open in your PDF viewer, and telling them apart by looking at your screen is nearly impossible:

1. A real PDF. Inside the file are text objects — actual character codes, positioned on the page, with a font program embedded so the glyphs render identically everywhere. Links are Link annotations: rectangles bound to a URI action. The file describes content.
2. A picture in a PDF wrapper. Inside the file is one giant image — a rasterized bitmap of what a page looked like — and a PDF container holding it. The file describes pixels.

Both look right. Only one is right. Here's what separates them.

Selectable text vs. a rasterized image of text

In a real PDF, the letters are letters. You can click and drag to select a sentence. Ctrl+F finds a word. Copy-paste gives you the word back, not a screenshot fragment. A screen reader reads it aloud.

In a rasterized PDF, the letters are an arrangement of coloured dots that your brain — and only your brain — resolves into words. Select-drag does nothing. Ctrl+F returns zero results in a document that visibly contains the word forty times. Copy gives you nothing, or gives you an image.

The test takes two seconds: open the file and try to select a sentence. If the cursor doesn't turn into a text I-beam and nothing highlights, you have a picture.

Embedded fonts vs. font substitution roulette

A real PDF can carry the actual font program inside the file. That's why a PDF made on your laptop with a licensed corporate typeface still looks right on a machine that has never heard of that typeface — the glyph outlines came along for the ride.

Without embedding, the viewer plays substitution roulette: it picks something it has locally that seems close, and your carefully-set document reflows, your table columns shift, and your headings suddenly look like a ransom note. This is the single most common reason a document "looks fine on my machine" and arrives broken.

Embedding is a spec-level feature. It's in the standard. It's the kind of thing errata collections exist to keep unambiguous.

Link annotations vs. blue text that does nothing

This one catches people constantly. In a real PDF, a hyperlink is a link annotation — a defined rectangle on the page with an associated action, usually "open this URI." Click it, something happens.

In a rasterized PDF, a hyperlink is blue underlined pixels. It looks exactly like a link. It is decoratively, cosmetically, entirely a link. Click it and nothing happens, because there's no annotation there — just a blue-ish region of an image. We wrote a whole piece on getting this right in save a webpage as a PDF with clickable links, because it's the failure people notice last and resent most.

Structure: the part almost nobody gets right

Above text, fonts, and links sits a further layer: the structure tree — tags that say "this is a heading," "this is a table, and these cells belong to this row," "read this column before that one." That's what makes a document navigable rather than merely readable, and it's the foundation of tagged PDF and archival profiles.

We'll come back to this in the honesty section, because it's exactly where our ceiling is.

Real PDF vs. image-in-a-PDF

That last row deserves a flag: once text has been rasterized, the only way back is OCR, and OCR is guesswork with a good hit rate — not recovery. We don't have OCR and we're not going to bolt it on to paper over a problem that's better solved by never rasterizing in the first place.

Why screenshot tools produce a picture in a wrapper

Full-page-capture extensions — GoFullPage-style tools — are built for a genuinely different job: capture what the page looks like. They scroll the page, stitch screenshots into one tall bitmap, and can wrap that bitmap in a PDF container. For "show me exactly what this looked like, pixel for pixel," that's the correct architecture. It's not a criticism; it's a design goal.

The problem is the export button that says "PDF," because it implies a document and delivers a photograph. What you lose, concretely:

• Search. Gone. A 40-page captured document you can't Ctrl+F is an archive you'll never use.
• Copy. Gone. You'll retype quotes by hand.
• Links. Gone. Every reference is decorative.
• Accessibility. Gone at the floor. A screen reader finds an untagged image and reads nothing — which is why this matters well beyond convenience, as we covered in the European Accessibility Act and selectable text.
• File size. Inflated, often by an order of magnitude. Text is a few bytes per character. A full-page bitmap at retina density is megabytes of nothing.
• Reflow. Gone. Zoom in on a phone and you get bigger blur, not bigger text.

We compared the two approaches directly in GoFullPage vs. Convert: Web to PDF if you want the side-by-side. The short version: pick the tool by what you need the file to do later, not by what it looks like the moment it's created.

The honest part: we don't write a PDF writer

Here's the section that makes this post worth publishing.

We do not hand-roll a PDF writer. We don't have a team of spec lawyers implementing ISO 32000-2 from the text. We use other people's engines, on purpose:

• Web pages go through Chrome's own print engine, driven via the DevTools Protocol. That's the same engine behind Chrome's built-in "Print to PDF," maintained by Google against the specification, corrected as the specification is corrected.
• Files — images, CSV, Markdown, TXT, JSON, XML, local HTML — go through jsPDF, running entirely in your browser.

Both run on your machine. Nothing uploads. But the point right now isn't privacy — it's competence, and knowing where ours ends.

Why this is a decision, not a shortcut

Our manifesto says software should be small. The corollary nobody puts on a landing page: you do not reimplement a thousand-page ISO standard as a side project. A four-extension indie shop writing its own PDF serializer would produce something that renders fine in Chrome, breaks subtly in Acrobat, and mangles a font in Preview — and we'd spend the rest of our lives chasing those bugs instead of making the tool better.

Riding a maintained engine means the engine's correctness is our correctness. That's the trade. It's a good trade, and it's the honest reason our output is a real PDF while a screenshot tool's isn't: we didn't have to be clever. We just had to not rasterize.

Our ceiling is the engine's ceiling

Now the part a marketing department would cut.

We do not emit PDF/A archival profiles. If your workflow requires a certified archival profile — a file guaranteed to render identically in 40 years, with a conformance claim attached — we are not your tool.

We do not emit tagged-PDF structure trees. You get real text, real fonts, real links. You do not get a logical structure tree with marked headings, table relationships, and reading order. That means we clear the accessibility floor and don't reach the ceiling.

We have no OCR. An image is an image. A photo of a page becomes a picture inside a PDF, and its text is not searchable. Full stop.

We can't read password-protected or encrypted source files. If the source is locked, we're locked out too.

If you need a certified PDF/A profile or a properly tagged, remediated document, the right answer is Adobe Acrobat or a dedicated PDF/A or accessibility-remediation tool — and we'd rather say so than sell you a one-click compliance fantasy. (If Acrobat's price is the problem rather than its capability, we've written about free Acrobat alternatives and where each one genuinely substitutes.) Tools like Smallpdf and iLovePDF are competent at their job too — the trade there is that your file takes a trip to someone's server to get it done, which is a different conversation.

We'd rather be the tool that's correct about a narrow thing than the tool that's vague about a wide one.

Why an errata release is good news for a small tool

Bring it back to June 18.

A standard that gets corrected is a standard that's alive. When 356 errata become 766 edits and approval climbs from 54% to 86%, the practical effect is that implementers have less room to disagree. Ambiguity is where incompatibility breeds. Every resolved erratum is one fewer place where two conforming tools can produce files that behave differently.

Now: who acts on those corrections? Engine maintainers. The people who ship the print engine in a browser used by billions of people, who have both the resources and the obligation to track the spec.

And here's the quiet payoff of our architecture. A tool that rides a maintained engine inherits those fixes for free. We don't have to read EC3. We don't have to triage 766 edits and schedule a quarter of spec-conformance work. The engine tracks the standard; we track the engine; you get the corrections without anyone at our end being heroic about it.

A tool that hand-rolls its own writer has to do that work forever, or quietly drift from the standard while still printing .pdf on the download button. A tool that takes screenshots doesn't participate at all — you can't drift from a specification you were never implementing.

That's not a boast. It's an admission: the smartest thing a small shop can do about a thousand-page ISO standard is stand next to someone who's already implementing it.

What this means for you, practically

If you take one thing from a nerdy errata release, take the test:

1. Open the PDF. Try to select a sentence. If nothing highlights, it's a picture.
2. Press Ctrl+F. Search for a word you can plainly see. Zero results means pixels.
3. Click a link. Nothing happens? Decorative.
4. Check the file size. Ten pages of text at 15 MB is a bitmap wearing a costume.

Run that on whatever converter you're using right now. It takes ten seconds and tells you more than any feature list.

If you want the full breakdown of which formats produce what on our end, the complete format guide covers every file type we handle and what comes out the other side. And if you're deciding between a browser's built-in export and an extension, Chrome's Print to PDF vs. an extension walks through where each one wins.

Frequently asked questions

Does PDF 2.0 Errata Collection 3 change anything about my existing PDFs?

No. An errata collection corrects the text of the specification, not files that already exist. Your PDFs are unaffected. What changes over time is how consistently different tools interpret edge cases — which is a slow, invisible improvement you benefit from without noticing.

How do I tell if a PDF is "real" without any tools?

Open it and try to select a sentence with your cursor. Real text highlights and the cursor shows a text I-beam. A rasterized page does nothing. Then press Ctrl+F and search for a word you can see on screen — if it returns nothing, the file is an image in a PDF wrapper.

Does Convert: Anything to PDF produce PDF/A files?

No. We do not emit PDF/A archival profiles, and we're not going to imply otherwise. If you need a certified archival conformance claim, use Adobe Acrobat or a dedicated PDF/A tool. We produce a real, dated, text-bearing PDF for your records — that's a different thing, and it's what most people actually need.

Is a PDF from a screenshot extension accessible?

No. A screen reader encountering an untagged full-page image finds nothing to read. Real selectable text is the floor for accessibility, and a rasterized capture fails at the floor. It's worth stressing that real text alone isn't full accessibility either — tagging and alt text sit above it — but you can't have those without text existing first.

If I convert a photo of a document, will the text be searchable?

No. We have no OCR. A JPG or PNG of a page becomes an image placed inside a PDF. The result is a perfectly good PDF containing a picture — the picture is not searchable, selectable, or readable by a screen reader. If your source is a photo, that's the ceiling, and we'd rather you know before you convert 60 pages.

Why use Chrome's print engine instead of writing your own?

Because ISO 32000-2 is roughly a thousand pages and gets corrected in batches of hundreds of edits. Implementing it correctly is a full-time job for a team, forever. Chrome's engine is maintained against the spec by people who do exactly that. Standing next to that work means our output stays correct without us pretending to expertise we don't have — and it's why our ceiling is honestly described as the engine's ceiling.

Does Markdown or CSV conversion produce real text too?

Yes. Files go through jsPDF, which places real text objects on the page — so a Markdown note or a CSV table comes out searchable and selectable. Images are the exception, and for an obvious reason: an image was always pixels. Converting a JPG gives you a PDF with a picture in it, exactly as expected.

Bottom line

PDF 2.0 Errata Collection 3 is the least glamorous release of the year: 356 errata, 766 edits, 86% ISO-approved, published June 18, 2026, and destined to be read by almost nobody. It's also the best available argument for a boring converter. Standards get corrected. Engines track the corrections. Tools that ride a maintained engine inherit the fixes; tools that take screenshots were never in the conversation, because a picture of a document isn't a document.

Convert: Anything to PDF produces real PDFs — selectable text, embedded fonts, clickable links — because Chrome's print engine and jsPDF do the writing and we had the sense not to. It's free, there are no watermarks, no size limits, and no account. It also won't give you PDF/A, won't give you tagged structure trees, and has no OCR — and if you need those, Adobe Acrobat or a dedicated tool is the right answer, not us.

Being clear about the ceiling is the only way the floor means anything.