Why is Buffer.byteLength larger than the decoded Base64 buffer?

Measured inputs and outputs

These are locally constructed test strings, not evidence that Claude inserts these characters. We executed the saved homepage script snapshot with a minimal DOM harness and compared exact strings. The invisible-checkbox state and dash mode appear in each row. The observations below test this page's specific question. Destination observations run independently on the exact input and cleaned strings in the recorded Node runtime. We make no detector-score or statistical-watermark removal claim.

The size estimate and actual output disagree

The first source inserts U+200B between the two Q characters of QQ==. Buffer.byteLength with the base64 encoding argument reports two, while Buffer.from decodes a one-byte buffer with hex 41. After the homepage removes the marker, the size estimate becomes one and the decoded buffer remains the same one byte. This is an important difference from an encoded hidden payload: the marker here is literal wrapper text and no decoded U+200B is involved. We save decoded hex and a canonical re-encoding alongside both lengths, making the exact output observable instead of assuming an estimate equals the bytes actually produced.

Whitespace and punctuation survive cleanup

The plain QQ== reference estimates and decodes one byte. A space inserted into the wrapper yields the same two-versus-one discrepancy as the marked input, but the cleaner leaves that space unchanged. The punctuation control with # also remains unchanged and has the same recorded discrepancy. All four outputs decode to hex 41 in this Node runtime and re-encode as QQ==. These controls show why a no-findings message cannot reconcile every size mismatch and why permissive acceptance by this decoder cannot establish a strict alphabet policy. We report the actual controls instead of generalizing to every malformed Base64 spelling or another decoder.

Allocate and validate under separate rules

If actual decoded size matters, obtain it from the decoded buffer at the stage where those bytes exist. If an application accepts only a strict Base64 grammar, validate that grammar independently before relying on a permissive decoder. Do not use a convenient length estimate as an authentication, content-type or integrity check. Preserve the original wrapper when rejecting malformed input so an operator can see whether it contained whitespace, punctuation or an unwanted selected character. Our observer does not fetch an attachment, execute decoded content or treat canonical re-encoding as proof that the original spelling met an application’s input policy.

A size question differs from payload inspection

The earlier Base64 guide decodes a deliberately encoded hidden character and explains why cleaning ASCII wrapper text cannot remove that payload character. This page measures the size API on wrappers containing literal extra characters and compares it with the real decoded buffer length. No payload text is cleaned after decoding. The one-byte output is an authored control, not a sampled document or signature. The runtime and full script make the discrepancy reproducible, while other encodings or Node versions require their own records. These bytes do not identify an author, detect hidden watermark information or demonstrate removal of a statistical signal.

Reproduce this test

Save reproduce.cjs and tested-app.js in the same folder. Run the command below with Node.js. The harness prints its runtime, script SHA-256 and every measured row. Compare those rows with the original record. Using a newer script or runtime creates a new experiment; retain the version information with your rerun.

node reproduce.cjs