Why my new Short leads with 125.7% — a number you can't use

I just recorded a walkthrough about a metric that keeps surprising people: my PDF-to-Markdown converter once produced output measuring 125.7% of the original file's byte size. Conversion that makes the file bigger sounds like a bug, so the Short exists to explain why it isn't.

Here's the concrete detail: when the converter hits a table on page 3, it doesn't flatten it into prose. It emits pipe syntax — | cell | cell | with a |---|---| separator row — and every row gains delimiters the raw PDF didn't need to spell out. Headings gain # prefixes, lists gain - markers. Markdown buys you structure at the cost of bytes, and for a dense report full of tables that overhead can push past 100%.

The thing it costs the operator is token budget. Nobody converts a document to shrink the file; they do it to feed an LLM. So every extra byte of Markdown is tokens burned in the context window, which is why the API has a length cap and why I have to care about markup overhead even when the source file is tiny. The walkthrough walks through one real PDF where I show the byte counts side by side, then show the capped output that actually fits a model's window. It's up at https://www.youtube.com/shorts/-5Qp4LlyBQA