pdfpanel strips whitespace, comments, and duplicate lines using plain rules, not a semantic compression algorithm. It doesn't summarize and doesn't understand meaning. It works great on some content and does almost nothing on other kinds. Below are the real numbers we measured, not the flattering average.
Content type
Standard
Aggressive
Hyper-Packed
Commented code, braces (JS/C/Java/Go)
0%
48%
55%
Commented code, indented (Python/Ruby)
1%
40%
40%
Formatted JSON
0%
39%
39%
Repetitive logs†
98%
98%
98%
Clean prose (PDF/DOCX text)
0%
0%
0%
Multi-page PDF, repeating header/footer‡
0%
52%
55%
TSV / Makefile (tab-delimited)
0%
0%
0%
CSV, no duplicate rows
0%
0%
0%
CSV, with repeated rows†
91%
91%
91%
† With Log Collapsing turned on. It's a separate toggle from the level slider, built for repeated lines like heartbeats and retries.
Where this genuinely helps
Commented, whitespace-heavy code sees a real cut, but how much depends on the language. Brace-and-semicolon code (JS, C, Java, Go) reaches 55% at Hyper-Packed, because its line breaks are decorative and can be removed. Indentation-scoped code (Python, Ruby, YAML) stops at 40%: Hyper-Packed matches Aggressive there because joining those lines would produce a file that no longer parses, and we would rather report the smaller number than hand you broken source. Earlier builds of this tool did exactly that and claimed 50%. Repetitive logs do best of all. In our own test, Log Collapsing took a 1,751-token log down to 58 tokens by collapsing 60 near-identical heartbeat lines into one marker. Pretty-printed JSON also does well from Aggressive onward. We actually parse it, not guess, to confirm it is valid, then re-serialize it minified, stripping indentation that only existed for human readability. Standard skips this on purpose. That level is meant to stay readable. Multi-page PDFs are a newer finding: real reports almost always repeat the same header, footer, and page number on every page, and we now detect and strip that automatically from Aggressive onward, using each line’s actual position on the page rather than guessing from the text alone. An 8-page test document saved 52%, all of it noise that had nothing to do with the actual content.
Where it does almost nothing
Clean prose, CSV with no repeated rows, and tab-delimited files. All three are already token-dense: no comments, no redundant whitespace, no repeated lines. There is nothing for a stripper to remove. A PDF-extracted report saved 0% at every level. A clean, deduplicated CSV also saved 0% at every level, and TSV and Makefiles now save 0% because we stopped collapsing their tabs, which is the honest result rather than the one that looked better. CSV with real repeated rows is a different story, covered below. If your file is mostly unique prose or already-deduplicated data, do not expect much here. We would rather tell you that now than have you find out the hard way.
A case we almost missed: CSV with repeated rows
Log Collapsing isn't actually restricted to files that look like logs. It collapses any run of near-identical lines, in any file type. A CSV with genuinely repeated rows, like event exports or polling data, gets the same treatment as a repetitive log file. In our test, a CSV with 50 near-identical rows saved 91%. The feature was already built. We just hadn't tested it on CSV until now.
Duplicate Collapse, a separate toggle
This is not another level. It is a standalone toggle that runs before everything else: exact repeated lines get replaced with one copy plus a count, like line text [×3] , instead of being silently deleted. Matching is exact after trimming whitespace only, case-sensitive, no fuzzy matching. That is also what keeps it safe: two log lines with different request IDs or error codes are different strings, so they are never merged, with no special-case rule needed for either. It never touches source code, fenced code blocks, or CSV and tab-delimited files, since duplicate CSV rows already have their own handling further up this page.
Content type
Duplicate Collapse alone
Heartbeat log, no timestamps
96%
Support thread with a repeated footer
41%
Notes export with a repeated header line
38%
The repetitive-logs fixture above
0%
The last row looks like a bug and is not one. That fixture's lines carry a different timestamp each time, so they are not exact duplicates, and this toggle correctly leaves them alone. Log Collapsing, above, is the feature built for that case: it tolerates the parts of a line that change and strips the parts that do not. Duplicate Collapse is for the case Log Collapsing does not cover, content that repeats verbatim with nothing varying at all, like a boilerplate footer or a repeated header line in an export.
On the token counts themselves
We count tokens with OpenAI's cl100k_base tokenizer (GPT-3.5/GPT-4). It's a real BPE tokenizer's real output, not a guess. Claude, Gemini, and Llama each tokenize somewhat differently, so treat these numbers as a solid reference point, not an exact count for every model.
Is this lossless? Can I undo it?
Standard, mostly: it strips trailing whitespace and collapses interior tab runs used for alignment. Leading tabs are preserved, and tab-delimited files are skipped entirely, so Makefiles and TSV survive intact. Aggressive and Hyper-Packed are genuinely lossy. Comments get deleted, not hidden. Blank lines get deleted. Log Collapsing replaces 50 near-identical lines with one marker and a count; the other 49 are gone. None of it is reversible. There's no stored mapping back to what you started with, so if you need the original later, keep the original file. JSON is mostly the exception: whitespace minification goes through a real parser and re-serializer, not a guess, so no key or value is ever altered. One part of the JSON path is not lossless though: exact duplicate objects in an array get removed, keeping the first and dropping the rest. Every kept record is byte-for-byte unchanged, but "this record appeared 3 times" becomes "this record appeared once," and that count is real information if you needed it. Same for CSV: duplicate rows and empty rows and columns are genuinely deleted, not hidden.
Does the AI actually understand the result?
We've verified the token counts are real. We have not run the optimized output through GPT-4, Claude, or Gemini and measured whether answer quality holds up against the original, and we won't claim otherwise. Published research on the question is mixed but leans reassuring: one study found models lean heavily on variable names (which this tool never touches) but showed no significant comprehension effect from comments being present or absent; a long-context benchmark found removing comments improved results for most models tested, though not for Gemini specifically. A separate study found comment stripping measurably hurt a weaker model on a security-review task. Take that as a reasonable signal, not a guarantee.
What this tool doesn't cover
pdfpanel shrinks what you send an AI, before it ever reaches a model. It has no way to shrink what the AI sends back. That's a genuinely different half of the cost problem, and other tools are built specifically for it. Coding-agent skills like Caveman work by instructing the model itself to reply more tersely, cutting the tokens it generates on the way out. Nothing here conflicts with that. Use both, and you're covering input and output instead of just one side of it.
If you use an agent or chat platform that supports a persistent instruction, this is a plain one you can paste in. It won't shorten code, commands, or exact numbers, only the filler around them.
Answer tersely. Cut greetings, restating the question, and filler like "I'd be happy to help" or "great question." Use sentence fragments where the meaning stays clear. Never shorten code, commands, numbers, file paths, or exact error text. Give the full explanation when one is genuinely needed. Brevity is the default, not a hard limit.
Copy prompt