The five-second check that decides everything
Open the statement and try to drag-select a figure. If the numbers highlight, the file carries a text layer. If nothing highlights, it’s a scan, a photograph of a page wearing a PDF’s clothes.
That one difference decides which of the two routes below can help you. On a scan, re-encoding the image can take most of the weight off. On a statement the bank generated as text, the same operation adds weight instead: in our own runs, re-rendering a 20-page text document at the highest quality setting produced a file 461 times the size of the original.
The tool runs both routes and keeps whichever came out smaller, so you never have to guess. Knowing which kind you have still tells you what to expect, and what the smaller file cost you.
What the two routes actually do
Route one rearranges the file’s internal structure and drops whatever is no longer referenced. Nothing is re-drawn, so every pixel survives exactly as it was. It’s the only route that leaves text selectable, form fields fillable, links clickable and bookmarks intact.
Route two renders every page into a fresh image at the resolution and quality you pick, encodes it, and builds a new PDF out of those images. This is where the large reductions come from, and it’s also where the text layer goes.
Both finish, both sizes are shown, and the smaller file is what you download. That’s the whole design, so you’re not asked to pick a strategy you have no way to evaluate.
- Faithful: 200 dpi
- Reads and prints normally. The safe choice when someone will look at it closely.
- Balanced: 150 dpi (default)
- Where most statements land: legible on screen and in print, and clearly smaller.
- Strong: 110 dpi
- Fine to read on a screen, soft if anyone prints it.
- Extreme: 80 dpi
- The largest reduction. Small figures and stamp impressions start to lose their edges.
- Custom
- Resolution 60–300 dpi, image quality 30–95%, optional grayscale, optional metadata stripping.
- Pixel ceiling
- Very large pages are quietly scaled down to stay under the renderer’s limit, so a 300 dpi setting on a big page may not really be 300 dpi.
What we measured, and what we measured it on
We can’t show you a benchmark run on real bank statements, and the reason is the same reason this site exists: nothing is ever uploaded to us, so there’s no pile of customer statements here to measure. A site showing a table of “1,000 real statements” either kept copies of them or made the number up.
So we built five sample files whose characteristics are known, because they’re generated by a script that ships with this project. You can read it, run it, and get the same figures. The samples stand in for the shapes a statement usually takes: a long text document, a page-sized bitmap at scanner resolution, a fillable form, a bitmap with form fields drawn on top of it, and a mixture of text and image pages.
- Bitmap pages at the highest setting: 1.8 MB → 84 KB, a 95.5% reduction. These pages had no text layer to begin with, so nothing readable was lost.
- Bitmap carrying eight form fields, moderate setting: 1.8 MB → 1.4 MB, a 25.3% reduction, and the form fields went from eight to zero.
- Twenty text pages, moderate setting: the image route produced a 9.8 MB file against a 21.8 KB original. The tool chose the lossless route, and the output was 21.7 KB.
The part that catches people out
A statement usually gets compressed because a portal refused it. It’s then read by the same class of software that refused it: lenders and visa processors run automated checks over statement files, and those checks read text.
If what you send back is a stack of images, that reading fails, and it tends to fail quietly. The upload is accepted, nothing looks wrong, and days later a human opens it, or an email arrives asking for the documents again without saying why.
When the statement is going somewhere that reads it with software, tick Keep the editable structure. That skips the image route entirely, so the text layer, form fields, links and bookmarks all survive. The file is usually larger, and the tool says so in the result rather than quietly handing you the smaller one.
When it comes out bigger
It happens, and the tool states it: the result panel reports the increase as a percentage instead of handing you a larger file with a tick beside it. Text-based statements are the usual case, because there was never much to take out and the image route only ever adds.
If the file still won’t clear the limit, the honest options are to send fewer months, to send just the pages that matter, or to accept the smaller reduction the lossless route gives you. There’s no fourth option that keeps everything and costs nothing.
One more thing worth knowing: compression leaves the content alone. If the account number shouldn’t be leaving with the file, shrinking it changes nothing about that. The redact tool is the one that removes text, and it runs the same way, in your browser, before you get here.
What leaves the file on the way
- Document metadata
- Title, author, producing software and timestamps are removed when that option is on, and it’s on by default.
- Text layer
- Gone if the image route won. The result panel says so plainly.
- Form fields, links, bookmarks
- Gone if the image route won, and preserved when Keep the editable structure is ticked.
- Page content
- Untouched by the lossless route. The image route re-draws it at the resolution you chose, which is a real change and not a reversible one.
