Job portals, visa applications, university admissions and tax offices love a hard upload cap: "PDF only, maximum 200 KB". Your scanned degree certificate is 4.8 MB. Here is how to get it under the limit without turning it into an unreadable grey smear, and why some PDFs refuse to shrink.

First, figure out what the PDF is made of

A PDF is a container. Its size comes from three things:

1. Embedded images — scans, photos, logos. In a scanned document this is 95%+ of the file.
2. Fonts — a fully embedded font family can add 200–800 KB on its own.
3. Everything else — text, vector drawings, form fields, metadata, sometimes an embedded thumbnail of every page.

A text-only PDF exported from Word is usually 50–150 KB already. If yours is 5 MB, it's almost certainly images. That's good news, because images are the part you can compress hard.

The math for scanned pages

Say you have a 2-page scan and a 200 KB limit. That's ~95 KB per page, leaving a little for the PDF structure. A JPEG of an A4 page at 150 DPI is roughly 1240×1754 pixels. At quality 60–70 in grayscale, a text page lands at 60–120 KB. In colour, double that.

So the levers, in order of impact:

• Resolution (DPI): going from 300 to 150 DPI cuts pixels by 75%. 150 DPI is perfectly readable on screen and when printed at A4. 100–120 DPI is still legible for typed text.
• Grayscale: if colour doesn't matter (most certificates, IDs for internal checks, signed forms), dropping colour saves 40–60%.
• JPEG quality: 60–75 for documents. Text edges get slightly soft but remain readable.

Doing it in the browser

Nibbo's "compress PDF to 200 KB" tool takes the target size as the goal and works backwards: it re-encodes the embedded images at progressively lower resolution and quality until the file fits, then stops. It runs entirely in your browser tab, which matters here — the files people squeeze into 200 KB are diplomas, passports, bank statements and payslips. None of that should be uploaded to a random compression site.

1. Open the tool and drop the PDF.
2. Run it. You'll see the resulting size and can preview pages.
3. Zoom to 100% on the smallest text (stamps, signatures, serial numbers) and make sure it's still legible.
4. Download.

If 200 KB destroys readability, check whether the form actually allows multiple files; splitting a 4-page document into two uploads at 200 KB each doubles your budget. There are also presets for 100 KB, 300 KB, 500 KB, 1 MB and up.

When a PDF won't compress

• It's already text-only. Fonts and structure can't shrink much. Try re-exporting from the source app with "minimum size" or standard fonts.
• It contains a huge vector drawing (CAD exports, maps). Images aren't the problem, so image compression won't help. Rasterise that page to an image at 150 DPI.
• It's encrypted. Some tools can't rewrite a protected PDF. Remove the restriction first if you own the document.
• It's a PDF/A archive copy. PDF/A forbids some optimisations. If the portal doesn't require PDF/A, a normal PDF is fine.

A checklist before you hit "Submit"

• Every page present, in order.
• Smallest text legible at 100% zoom.
• Signature and stamp visible.
• File name sensible (Lastname_Degree_Certificate.pdf, not scan0003.pdf).
• Size under the limit, not equal to it. Some portals count 200 KB as 200,000 bytes, others as 204,800. Aim for ~190 KB to be safe.

Bonus: start from a better scan

If you're scanning again anyway, scan at 150–200 DPI in grayscale, not 600 DPI colour. You'll get a smaller, cleaner file from the start, and the compressor has less work to do. Phone "scan document" modes are fine too, as long as the page is flat and evenly lit — shadows and gradients cost bytes.

The browser of 2026 can do most of this work itself. This post walks through how a serverless, in-browser converter is put together, using Nibbo as the reference: a free toolbox that compresses and converts video, images, audio and PDFs on the user's device, with video files up to 3 GB.

The architecture: a static site and the user's hardware

A client-side converter is, from the network's point of view, a static website. The server ships HTML, JS and WebAssembly modules. After that, the file the user drops never goes anywhere: it is read with the File API, processed in the tab (ideally in a Worker), and handed back as a Blob for download.

That has a few nice side effects:

• No queue. Every user brings their own CPU and GPU. Ten thousand concurrent users cost the same as one — a CDN bill.
• Offline after first load. Nibbo's own docs suggest a simple test: open a tool page, switch on airplane mode, and convert. If it still works, there is nowhere for the file to be uploaded to.
• Verifiable privacy. Open DevTools → Network, filter by method:POST, run a conversion. A server-side converter shows a request roughly the size of your file. A client-side one shows page assets and maybe a few KB of analytics.

The hard parts are all on the client: codecs, memory, and performance on hardware you don't control.

Two engines: WebCodecs and ffmpeg.wasm

There are two realistic ways to transcode video in a browser today, and they have very different profiles.

WebCodecs: the hardware path

WebCodecs exposes the browser's own decoders and encoders — the same ones used for video playback and WebRTC — as VideoDecoder and VideoEncoder. On most machines that means hardware-accelerated encoding on the GPU or media engine.

Strengths:

• Fast. Hardware H.264 encoding runs at many times real-time on ordinary laptops.
• Frames are VideoFrame objects that can stay in GPU memory, so you avoid copying every frame into the WASM heap.
• Low CPU usage, so the tab doesn't melt the fan.

Weaknesses:

• WebCodecs only does codecs, not containers. You still need a demuxer (MP4, WebM, MKV parsing) and a muxer to write the output.
• Codec support depends on the browser and OS. VideoEncoder.isConfigSupported() is your friend, and you need a fallback.

ffmpeg.wasm: the compatibility path

ffmpeg.wasm is FFmpeg compiled to WebAssembly. It understands practically every container and codec FFmpeg does, which makes it the safety net for odd inputs: old AVI files, exotic audio, formats the browser simply can't decode.

The trade-offs are the mirror image of WebCodecs:

• Software-only encoding, so it is much slower, especially for video.
• It runs inside a WASM linear memory, which is where the size problems start.

Combining them

The practical design is a router: try the hardware path first, fall back to WASM when the browser can't decode the input. Nibbo's compressor describes exactly this: "Your GPU encodes it through WebCodecs. Formats the browser cannot decode go through FFmpeg compiled to WebAssembly."

Memory: why "3 GB in a browser" is not trivial

The naive ffmpeg.wasm workflow is: write the input file into the in-memory virtual filesystem, run the command, read the output file back. For a 3 GB video that means 3 GB of input plus the output, all inside a WASM heap — and 32-bit WebAssembly memory tops out at 4 GB, with real browsers often refusing large allocations well before that. Mobile Safari will kill the tab much earlier.

So a converter that handles multi-gigabyte inputs has to avoid holding the file in memory at all. The general techniques:

1. Stream from the File handle. A File is a Blob; file.slice(start, end) lets you read chunks on demand without loading the whole thing. Demuxers can pull just the byte ranges they need.
2. Keep frames out of the heap. With WebCodecs, decoded VideoFrames can be fed straight into the encoder. Call frame.close() promptly — leaked frames are the most common way to exhaust GPU memory.
3. Apply backpressure. Watch encoder.encodeQueueSize and decoder.decodeQueueSize, and stop feeding when they grow. Otherwise a fast decoder will happily queue thousands of frames.
4. Write output incrementally. Encoded chunks go to a muxer that writes to disk-backed storage (OPFS, or a streaming download) instead of an ever-growing ArrayBuffer.
5. Run in a Worker. Keeps the UI responsive, and isolates the heavy allocations from the main thread.

Done this way, peak memory is governed by the number of frames in flight, not by the file size. That is what makes a 3 GB ceiling realistic on a normal laptop.

Hitting an exact target size

A detail I liked in Nibbo's video compressor: you pick a target in MB (say, under Discord's 20 MB free limit or Gmail's 25 MB), and the tool works backwards. Per its own description, it measures how detailed (spatial information, SI) and how much in motion (temporal information, TI) the clip is, computes a bitrate budget from the target size and duration, then picks resolution and frame rate to fit that budget — on the principle that a lower resolution with enough bits beats a blocky full-resolution picture. If the output still comes out slightly over the limit, it re-encodes with a corrected bitrate.

The math itself is simple (bitrate ≈ target_bits / duration, minus audio and container overhead); the hard part is that hardware encoders don't hit bitrates precisely, which is why the correction pass matters.

Not just video

The same approach extends to everything that is CPU-bound and doesn't actually need a server. Nibbo's sitemap lists well over a hundred tool pages, including:

• Images: HEIC/WebP/AVIF/JPEG XL/PNG/JPG conversion, compress-to-exact-KB for exam and government portals, crop, resize, EXIF removal without re-encoding.
• PDF: merge, split, compress, OCR in 25 languages, PDF to Word/Excel, AES-256 protection, signing.
• Audio: cutters, normalization, LUFS meter, format conversions.
• Developer utilities: JSON formatter with schema validation, a JWT decoder that verifies signatures locally, hash generator.
• On-device AI: face blurring, auto subtitles, a redaction tool that strips emails, phone numbers and card numbers before you paste content into an AI chat.

Several of these (the JWT decoder, the redaction tool, the e-invoice viewer) are tools where uploading the input would defeat the point entirely.

Where client-side still loses

Honest limitations of the model:

• Hardware variance. A five-year-old phone will be slow, and some browsers lack certain encoders. You need graceful fallbacks and clear messaging.
• Software fallback is slow. When ffmpeg.wasm does the encoding, expect it to be far slower than native FFmpeg.
• Size ceilings exist. Even with streaming, there are practical limits; 3 GB is Nibbo's stated cap for free use.
• Cold start. WASM modules have to be downloaded once. Caching helps, but the first run costs bandwidth.

Takeaways

If you are building anything that touches user files — media tools, document utilities, dev tools — it's worth asking whether the server is actually necessary. WebCodecs gives you fast hardware encoding, ffmpeg.wasm covers the long tail of formats, and careful streaming keeps memory bounded. The result is cheaper to run and privacy you can verify with DevTools instead of a promise in a policy.

To see the approach in practice, open nibbo.org with the Network tab open and run a conversion. Watching nothing upload is the clearest demo.