I compressed the same 5 PDFs with 6 tools. Three of them deleted every screen-reader tag.

The results

6 products were measured. Adobe Acrobat Online and Sejda have recorded settings and no captured output, so they are named in the methodology rather than counted here.

Two questions, because "which one made the smallest file" is only half of one.

Kept everything ranks the tools that handed the whole document back: every page, every character, every accessibility tag, every form field and value, every link and bookmark, and pages that still render like the original.

Smallest, whatever it took ranks the same tools by size alone. Everything in it still opens and still lets you search the text. The last column says what each one gave up to get there, on one fixed scale, so two rows can be compared without a degree in PDF internals.

The first tab is the overall standing. The other five are the individual documents.

Round by round

Every column is measured from the file the tool handed back, not read off its result screen. A result screen tells you the size and nothing about the document.

The three websites were driven by hand in a real browser on the setting named in each row, on 27 August 2026. Whatever each one returned was saved and put through the same checks as everything else.

The 34,802 tags nobody mentions

Underneath every tagged PDF sits a second document you never see: a tree saying this is a heading, this is a table row, this is the alt text for that chart, and this is the order a human reads them in. Strip it and the page still draws exactly the same marks. What goes is any way of knowing what those marks *are*.

That tree is what a screen reader follows. It is what "accessible PDF" means, and for federal agencies it is how a document meets Section 508.

iLovePDF removed it. Smallpdf removed it. Ghostscript removed it at /screen, /ebook and /printer alike. Every tag, in every tagged file I tested. iLovePDF and Smallpdf remove the catalogue entry too, so the file stops claiming it ever had one.

The two websites do this on the setting a free visitor is handed — iLovePDF's "Recommended", Smallpdf's "Basic". Ghostscript has no default in the same sense; the point there is that no preset avoids it.

Why bother? Because the tree is worth a great deal of file size. I measured it the only way that settles the question: compress each document twice with the lossless passes only, once keeping the tree and once detaching it, and subtract.

• Publication 17: 1,160 KB, 38.5 points. 4.69% with the tree, 43.16% without.
• The federal budget: 595 KB, 25.2 points. 9.59% with, 34.81% without.
• The Census report: 580 KB, 21.8 points. 15.79% with, 37.60% without.
• Form 1040: 32 KB, 14.8 points. 42.20% with, 56.95% without.

No image work, no font work, the two runs identical in every other respect. pnpm compress:tag-cost reproduces them.

Now read the board again. iLovePDF's 74.42% on the Census report is real, and around 22 points of it is the accessibility tree.

Offering that trade is reasonable. On 30 August 2026 iLovePDF's compress page carried the title "Compress PDF online. Same PDF quality less file size" above "Reduce file size while optimizing for maximal PDF quality." Smallpdf's read "Shrink PDF Size, Preserve Quality". Not one of those sentences is false about what you can see. Every one of them is silent about what you cannot.

We do it too, and here is the difference

A report that scolds other people for something it also does is worth nothing. So: our Smallest setting removes the structure tree, the operators binding it to the page, private application data, XMP metadata and any embedded attachment large enough to matter.

There are real reasons to want that — a brochure going into an email, a file that has to clear a portal limit today. The trade is not the problem. Four things make ours different:

• It is not the default. Balanced is, and Balanced removes none of it.
• The control says so before you press it: "Photos soften. Removes screen-reader tags, metadata and attachments."
• The result afterwards counts what went — "34,802 accessibility tags removed" — and offers to redo it at Balanced.
• It is ranked in the second table as a tool that removed something, next to iLovePDF Extreme, because it did.

None of the six settings I tested elsewhere disclosed the trade before compressing or reported it afterwards. Smallpdf's stronger levels sit behind its paywall, so they are untested rather than cleared.

One correction worth keeping visible. Detaching that tree is harder than deleting a dictionary entry, and the first version of this report got it wrong. Removing /StructTreeRoot from the catalogue orphans the tree on three of these four files. On the Census report it orphans nothing, because every bookmark carries an /SE entry pointing into the tree, so all 34,802 elements stay alive through the table of contents. I published "the tree costs nothing on the Census report" in the opening line. It costs 580 KB. Corrected 27 August.

So which one should you use?

One test corpus cannot tell you about batches, encryption or price, and I build one of the tools in the table. So two of these three go to somebody else:

The thing none of the other five do, at any price, is check their own work. They compress the file, report a percentage, and stop. Ours re-opens the file it just wrote, reads it back with the same inspector the viewer tab uses, and reports from that — including anything it skipped and why. A compressor that only ever prints its wins is teaching you to trust it further than it has earned.

What each tool actually did

Lyonite. Balanced lost nothing on any of the five: every page, character, tag, form field and value, link and bookmark came back. Smallest is a separate, named setting that removes the tag tree, metadata and large attachments, and counts each of those afterwards. Weak spot: Type1 and CFF font programs, which we keep rather than subset.

iLovePDF. The strongest upload-based competitor with complete results, and on the CLIP paper its default beats our default outright while keeping everything — that paper has no tag tree, so there was nothing there to quietly delete. On the four tagged documents it removed every tag, and on the federal budget it emptied the form field as well.

Smallpdf. Two downloads per twelve hours on the free tier, so it is measured on two files rather than five and its rows say so. Both outputs lost their tags; the budget also lost its form field and value. The tax form's 199 fields came through intact.

PDF24. 144 PPI, quality 75, stream deduplication, heavy-graphics rasterisation, font subsetting. It kept every tag, field, link and bookmark on all five — the only online consumer tool here that lost nothing at all. It is also the one that made Publication 17 marginally bigger, which is the same limit our own writer had to solve.

Ghostscript. Deleted every tag on every tagged file at all three presets, lost text on four of five, emptied a page of charts on the research paper, and returned three of the five files larger than they went in. It is very good at pictures and it does not really believe in structure.

qpdf. A local command-line reference rather than a consumer product. Its lossless row recompresses streams and builds object streams without touching page appearance.

Adobe Acrobat Online and Sejda. Configurations recorded, no output captured, so no row. Neither is ranked and neither is estimated.

The page that vanished

Page 41 of the CLIP paper is a grid of 27 scatter plots, drawn as vector art, with the axis labels as real selectable text. In the original it is 31,188 drawing operations and 35.4% of the page is ink.

Ghostscript's output has 51 operations. Six text draws, one path, one stroke. 1.4% of the page is ink, and all of it is the running header, the page number and the caption:

Figure 20. Linear probe performance plotted for each of the 27 datasets, using the data from Table 10.

The charts that caption describes are gone. Not rasterised — there is no image operator on the page at all. Just gone, at /screen, /ebook and /printer alike, on Ghostscript 10.07.1.

This is the finding that changed how the report is run. The pixel comparison samples six pages out of forty-eight, and those six did not include page 41. The file scored 0.54% drift and looked fine. Every page of every output is now weighed for ink, which costs minutes and would have caught it on the first run.

Three of five files came back bigger

Ghostscript did not merely fail to compress the tagged documents. It inflated them.

Publication 17 went in at 2.95 MB and came out at 6.73 MB, 128% larger, with all 62,494 tags gone and three links broken. The federal budget went from 2.31 MB to 4.27 MB on /printer, the preset whose name sounds safest. The Census report went from 2.60 MB to 4.23 MB.

The mechanism is not mysterious. Ghostscript rewrites the document rather than repacking it, and its rewrite is generous with objects and stingy with object streams — so a file whose bulk is tens of thousands of small structural objects comes out worse than it went in.

This matters beyond the table because "just run it through Ghostscript" is the most repeated answer to "how do I compress a PDF", and on a tagged government document it is wrong in both directions at once.

Why size on its own is a worthless measure

Ask any compressor how it did and it answers in megabytes. That is the easy half of the question. A tool that deleted every page but the first would win it outright.

A PDF can be made dramatically smaller by rendering each page to a picture and throwing away everything underneath — the text, the links, the form fields, the bookmarks, the tags. It looks identical on screen and it is a different kind of object. You cannot search it, copy from it, fill it in, or hand it to a screen reader.

So every output here is compared against its original on nine measures, not one, and the two that decide the ranking are in the tables above: what the document lost, and how the worst page looks.

Where we still lose

iLovePDF's default beats our default on the CLIP paper, 70.73% to 65.79%, without removing anything. That paper has no tag tree and no form, so the whole argument of this page is inapplicable to it — iLovePDF simply produced a smaller file, and a slightly closer one: worst-page SSIM 0.9985 against our 0.9957.

I know most of where the difference is. Their output holds 112 KB of embedded font programs where the original holds 1,385 KB. Ours keeps more, because our subsetter handles TrueType and leaves Type1 and CFF alone rather than guessing at them. That is a real gap and a fixable one, and until it is fixed this row says so.

PDF24 crushes vector artwork and we do not. A reader sent me a 50 MB file that is a single page: two 11-megapixel images and a 24 MB *uncompressed* page description. It is not a sixth round — it is not a public document, and only two of the services could be run on it — but it says more about the trade on this page than another government report would.

• Lyonite Balanced: 6.84 MB, 86.35% smaller, all 164 drawing operations intact.
• Lyonite Smallest: 4.28 MB, 91.45% smaller, still all 164.
• iLovePDF, most aggressive: 5.79 MB, and 124 of the 164 operations.
• PDF24: 0.38 MB — 99.24% smaller, and 112 operations.

PDF24 wins that by a distance, and it is worth being exact about how: its output is one 2242×2242 JPEG and a 0.02 MB page description. It converted the drawing into a photograph of the drawing. The text is still text, which is genuinely good; the artwork is now a fixed-resolution image that blurs when somebody zooms and cannot be re-scaled. That is their documented heavy-graphics rasterisation, and on a file like this it is enormously effective. No setting here does it, and that is the honest cost of our position.

We will flatten pages in exactly one situation. If you type a size into "Make it under" — only then — the panel works out what reaching it takes and tells you first: *about 6 of 48 pages will become images.* Only the heaviest pages go, as few as it takes to cross the line, and the words are laid back over each one invisibly, the way a searchable scan works, so the page stays selectable. What is genuinely lost is that page's sharpness under magnification and its place in the tag tree. The file then carries a two-kilobyte record naming which pages were flattened and at what resolution.

And we are slower. Balanced took 2.5 seconds on the tax form and 10.6 seconds on the Census report. Smallest took 6.1 seconds and 53.1 seconds on Publication 17, which is the slowest thing here. Two reasons, neither of them a defect: the work happens on your laptop rather than in a datacentre, and Smallest deliberately runs zopfli, because somebody asking for the smallest possible file has said they will wait for it. If you want a 200-page scan crushed in two seconds, upload it to somebody.

Smallest is not "lossless except for tags", and this report should not imply it is. On the CLIP paper it is the one Lyonite row that drops below our own 0.990 worst-page SSIM floor, at 0.9838 — visible detail, on one page, measured and printed. The claim is that it removes less than the alternatives and says what it removed, not that it removes nothing.

Ghostscript /screen is smaller than us on the CLIP paper, and it got there by deleting a page of charts and 4% of the text, so it sits in the table with that written next to it rather than counted as a win.

The one column that cannot be tuned

Everything else on this page is a trade you could argue about. This one is not.

To use iLovePDF, PDF24 or Smallpdf you upload your document to a company's server. Whatever the retention policy says — iLovePDF's says two hours — the file left your machine, crossed a network, and sat on a disk you do not control. For a marketing brochure that is nothing. For a signed lease, a medical record, a contract under NDA, or the tax return in this very corpus, it is the whole question.

Our compressor runs in the page. There is no upload because there is no server to upload to, and that is verified rather than asserted: a script drives every tool on this site through a real browser with the network panel recording, and fails the build if any request carrying document bytes leaves the origin.

Ghostscript and qpdf are local too, and it is one of the two good reasons to use them.

Check it yourself in about a minute

Take any tagged PDF — one of the government documents linked in the tabs above, or something from your own work. Drop it into our compressor and read the line under the three settings. On the Census report it says:

• *Text, links, forms and 34,802 accessibility tags are kept.*

Now compress that same file at iLovePDF or Smallpdf, download what they give you, and drop their file into our compressor. It reads:

• *Text, links, forms and bookmarks are kept. This file has no accessibility tags in it.*

That is the whole claim of this page, reproduced on your own machine, without taking a single number here on trust. Do the same with PDF24's output and the 34,802 are still there.

It is also the check to run against us. Compress at Balanced, put our output back in, and the count should be unchanged. If it is not, that is a bug and I want to hear about it.

The longer version. Every file in the tables is a public document linked from its own tab, and the benchmark manifest records the size and SHA-256 of each, so you can confirm you are testing the same bytes I did. The checker is in the repo and takes a folder:

The three websites are the one part that is not scripted: they rewrite their own DOM, and a selector that works today is a broken measurement next month. Those uploads were done by hand, once, and the returned files went through the identical checks. Our own test files are at https://github.com/yorkzap/pdf-leak-corpus.

# every tool over a folder of PDFs, ours included
node scripts/compare-compressors.mjs ~/your-pdfs

# just ours, as a regression check
node scripts/compress-verify.mjs ~/your-pdfs

What this does not prove

Five documents is five documents. They were chosen to be different from one another — a vector-heavy paper, two tagged government reports, a fillable form, a long tagged guide — and not to flatter anybody. But a corpus this size finds behaviours, not frequencies. If you have a file that behaves differently, I would like it.

Our own text check has a blind spot, and something else had to find it. It compares the text from both files with the spaces taken out, so a file that lost a space still scores 100%. Two real documents did lose one, because we were rounding the numbers that position text on the page and the rounding closed a gap just enough that the extractor read two words as one. This page's checks would never have noticed. A separate run over sixty real PDFs, comparing character for character, did.

Smallpdf is measured on two files, not five. Its free tier allows two downloads per twelve hours and its stronger levels are paid. Its 77% on the Census report is a figure read off a result screen with no file behind it, which is exactly why it is not in the tables.

Defaults and strongest modes are different questions. The first table uses each tool's documented default; the second uses the strongest setting available for free and records what it cost. Paid-only settings were not purchased and are never replaced with guesses. And these are live services captured by hand on 27 August 2026, so every website result is a claim about one day and one configuration.

This is my own report about my own product, and we come out well in it. So: the checker is in the repo, all five inputs are public documents whose SHA-256 hashes are recorded in the manifest, and every figure in every table is read out of the JSON the checker writes rather than typed in by hand. Download the files and run it. If a number here does not reproduce, write to hello@lyonite.com and it gets corrected in public, usually within 48 hours.

Questions people ask about this