Loading today’s stories
Build1 distinct publisher3 min readPublished
Real headers and an exact byte count pull against each other, and every format loses the fight differently. One generator author walked 25 of them and catalogued the bugs that browsers forgive and CI parsers refuse.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
An exact byte budget is a search problem, and 18 encodes is the wrong way to run it1 distinct publisher
build
PDF extraction is reconstruction, not reading: budget the pipeline that way1 distinct publisher
build
The re-encode that quadrupled a GIF was passing every test that looked at pixels1 distinct publisher
build
Every PNG optimiser filters by default. On seven of eight animations that made the file bigger.1 distinct publisher
A strict PDF reader does not go looking for `endstream`. It seeks past the `stream` keyword, reads exactly as many bytes as `/Length` declares, and expects the closing keyword at the cursor. Declare 44 over a stream that measures 38 [4] and it consumes six bytes that were never part of the stream [24], then errors where the keyword should have been [6]. Lenient viewers scan instead of trusting the field, which is why the same bytes rendered in a browser and were refused by Acrobat and pypdf [5]. The second defect in the same object was quieter: `/Resources << >>` was empty while the content stream drew text with `/F1`, and viewers substitute a font silently rather than complain [7].
Both fields are the same category of mistake. `/Length` and the cross-reference offsets restate information the assembled bytes already contain, so the fix is to measure rather than predict, recording `body.length` for each object as it is appended [8]. That is a one-line change in the assembly loop, and it is the part of this writeup that generalises furthest.
Where padding may go is not the generator's choice. It is whatever region the format designates as ignorable. For PDF that is after `%%EOF`, which a conforming reader is required to skip [9]. For DOCX it is an XML comment before the closing tag, which python-docx and openpyxl both accept while the byte count stays exact [12]. For PNG it is a `tEXt` ancillary chunk before `IEND` with a correct CRC-32, because decoders skip ancillary chunks they do not know [13]. For JPEG it is `FFFE` COM markers holding up to 65,533 bytes each, chained, placed immediately after SOI [14]. That capacity sets the shape of the work: 25 MB of COM padding is at least 401 chained markers [25], and every library that walks the marker chain walks all of them. The author reports that padding near EOI decoded unreliably across libraries, that moving it fixed the problem, and that he never root-caused why [15]. That is an unexplained workaround, and saying so plainly matters more than inventing a tidy explanation.
The floors table describes one generator's output shape, with numbers specific to it: 69 bytes for JSON, 114 for XML, 170 for SVG, 600 for PDF [18]. Those numbers transfer only when your minimum document matches the same top-level structure, the same key or element names, and the same declarations; the failure mode, not the byte count, is what actually carries over to other generators. A 20-byte JSON request sits 49 bytes under that floor [26], and the generator quietly emitted whitespace of exactly the right size that failed `JSON.parse()` [17]. Rounding up and saying so is the honest answer.
PPTX is where generation from spec stopped paying. A minimal deck needs presentation.xml, presProps.xml, a slide master, a slide layout and a theme, with the master and layout referencing each other, and a small error produces a repair prompt [19]. The author now ships a known-good deck as a static asset, clones its blank slide, and patches three files [20]. Sizing comes from a binary search on `ppt/pad.xml`, an orphan part covered by the default XML content type and referenced by nothing [21]. The byte budget now rests on a reported behaviour: PowerPoint ignores unreferenced parts entirely [21].
The through-line is the acceptance test. Every bug listed passed the test the author was running [28]. A fixture that only opens in Word is a fixture for a human. The pipeline is run by something else [11].
Ranked by verification strength, evidence, and original report placement.
The obvious approach, dd if=/dev/urandom of=test.pdf bs=1M count=25, yields exactly 25 MB but produces a file that any format-sniffing validator rejects instantly because it is not a PDF.
The author built a generator for 25 file formats that emits real headers at exact byte sizes.
Real headers and an exact byte count are requirements that fight each other, and every format loses the fight differently.
Stated use cases include a 25 MB PDF to test an upload limit, a 105-page DOCX for pagination, and a 1 GB binary to benchmark throughput.
The generator's first PDF emitted a content stream object with a hardcoded /Length 44, while the actual stream is 38 bytes.
Browser viewers rendered the malformed PDF fine; Acrobat rejected it, and so did pypdf.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Checkable mechanics, unverifiable numbers
The mechanisms in this account can be tested against the formats themselves: a declared /Length of 44 over 38 bytes really does walk a trusting parser six bytes past the stream, decoders really do skip unknown PNG ancillary chunks, PowerPoint really does ignore parts nothing references. The post also does the one thing that separates a report from an anecdote — it quotes the failure, down to the lxml 'Extra content at the end of the document' string. Where it thins out is the arithmetic: the 69-byte JSON and 600-byte PDF floors are specific to his templates, and neither the templates nor the generator's code are offered, so nobody can rerun them.
One tool, self-reported
Adoption evidence begins and ends with the author. He says he maintains a client-side generator built on these techniques and that he validates it across six strict readers; there are no users, no downloads, no other project shown copying the padding placements. That is enough to establish the practice exists in one place and not enough to suggest it has spread.
Undersold as a formats hobby post
The framing is smaller than the finding. Presented as a changelog of one generator's bugs, the post actually lands a general result: a fixture validated against the most forgiving reader you own is a false green, and the author's own summary — every bug passed the test he was running — applies to far more than synthetic files. The headline promises a parse error and delivers a testing thesis.
A pitch, plainly labelled
The closing paragraph is promotion: the author maintains the browser-based generator the whole piece describes, and a detailed bug tour is effective marketing-by-competence. Two things blunt it. The disclosure is upfront rather than buried, and the content is unflattering — the thesis of the post is that his own early output was broken for everyone but the most forgiving reader.
Trust the mechanisms, hold the measurements
Confidence is asymmetric here rather than middling. The spec-level claims are consistent, internally coherent and checkable by any reader with pypdf and a hex editor, so they can be relied on. The parts that depend on the author's private setup — the byte floors, the flaky JPEG decoders, the 25-format breadth — rest on a single self-interested account with no code, no versions and no second observer.