How to generate a valid file of any exact size, in the browser

Byte Rivet — Wed, 05 Aug 2026 01:16:47 +0000

I needed a 10 MB PDF to test an upload limit. Not "about 10 MB" — exactly 10,485,760 bytes. Every generator I found gave me fixed sizes or made me wait for a server download.

So I looked into doing it in the browser. The interesting part wasn't the size. It was keeping the file valid while hitting an arbitrary byte count.

The naive approach breaks the file

The obvious move is: make a real file, then append junk bytes until you hit the target.

const blob = new Blob([realPdf, padding]); // ← corrupt

For most formats this produces a broken file. A PDF reader follows the cross-reference table to a byte offset; trailing garbage after %%EOF can throw it off. A PNG decoder walks length-prefixed chunks; extra bytes at the end aren't a valid chunk.

The trick is that every format already reserves a legal place for extra data. You just have to put the padding there.

Padding where the spec allows it

PNG → a tEXt metadata chunk. It has a length prefix and a CRC-32, so decoders read exactly its declared length and skip the rest. Perfectly valid.
PDF → an unreferenced content stream. Same mechanism PDF writers use for incremental updates — the xref table just doesn't point at it.
ZIP / DOCX / XLSX → a stored (uncompressed) entry inside the archive.
JPEG → COM comment segments, up to 65,533 bytes each.

For PNG, the padded chunk needs a correct CRC or the decoder rejects it:

function pngChunk(type, data) {
  const body = concat(type, data);
  const crc  = crc32(body);           // must be correct
  return concat(uint32(data.length), body, uint32(crc));
}

Get the CRC right and the file opens everywhere — the padding is invisible.

Why the browser part matters

Because nothing crosses the network, size barely affects speed. Assembling a 100 MB file is a memory operation, not a download — it lands in tens of milliseconds. And the file never leaves your machine, so there's no upload, no storage, nothing to log.

I verified the output against real parsers — pypdf reads the PDF text, Pillow decodes the PNG, openpyxl opens the XLSX. They're genuinely valid files, just padded.

I turned this into a free tool (ByteRivet) that does 19 formats at any exact size, all in-browser. But the padding-without-corruption idea is the reusable part — worth knowing whenever you need a fixture at a precise size.

What's the weirdest exact-size requirement you've hit in testing?

How to Test File Upload Limits with Exact-Size Test Files

Byte Rivet — Sun, 26 Jul 2026 01:28:17 +0000

File upload testing often looks simple:

Choose a file.
Upload it.
Confirm that it works.

But a single successful upload does not prove that the validation is reliable.

If an application accepts files up to 10 MB, the most useful test cases are not random files that are “around 10 MB.” You need files that sit directly around the configured boundary.

For a decimal 10 MB limit, that may mean testing:

9,999,999 bytes
10,000,000 bytes
10,000,001 bytes

These three files can reveal whether the application handles its upload limit correctly.

Why exact file size matters

Upload limits can be enforced at several different layers:

Browser-side JavaScript
Application server
Reverse proxy
Web server
API gateway
Cloud storage service
Database or object storage quota

These layers may not use the same limit or even the same measurement system.

For example, one part of the application may interpret 10 MB as 10,000,000 bytes, while another may treat it as 10 MiB, which equals 10,485,760 bytes.

I built ByteRivet to make this workflow easier.

That difference is large enough to produce inconsistent behavior.

A file may pass client-side validation but fail after the upload begins. It may also be accepted by the application but rejected by a proxy before reaching the server.

A basic boundary testing strategy

Assume your application has a maximum upload size of 10,000,000 bytes.

Create three files:


text
Below the limit: 9,999,999 bytes
At the limit:    10,000,000 bytes
Above the limit: 10,000,001 bytes