Skip to main content

Compress PDF to 500KB

Set a byte ceiling and the tool iterates render DPI and JPEG quality until the PDF fits under it, keeping the page count and page dimensions identical.

No watermarkFree & unlimited
Target file size

This re-renders every page as an image.

Layout, page count and page size survive exactly. Selectable text, search, links, form fields and screen-reader output do not — they become pixels. If you need the text to stay text, use the preset-based PDF compressor instead.

Nothing is uploaded. pdf.js renders each page to a canvas in a worker inside this tab, canvas.toBlob encodes the JPEG, and pdf-lib assembles the new document in page memory. The pdf.js worker is bundled with the site and served from toolchamp.app — no CDN fetch, no API call, no Pages Function. The download link is a blob: URL in the same tab.

A preset labelled Web optimised cannot promise you 500 KB, because it does not know what is in your document. This page inverts that: you give it 512,000 bytes and it iterates until the file is under them. Every page is re-rendered by pdf.js onto a canvas at a chosen DPI, encoded as a JPEG at a chosen quality, and reassembled by pdf-lib at the original page dimensions in points — so the page count, page size and layout are identical and only the raster detail changes. After each full render the real output size is measured and the next DPI and quality are solved from the miss rather than stepped blindly, which usually converges in two or three passes. The cost is stated up front, not buried: this turns text into pixels.

Key facts about Compress PDF to 500KB

Key facts about Compress PDF to 500KB
What 500 KB means here512,000 binary bytes, measured on the assembled PDF blob before the download link appears
Measured examplea 3-page A4 document with a full-width photo on every page, 1.29 MB in, finished at 489,089 bytes
Passes that tookthree: 150 DPI at quality 0.72 gave 837 KB, quality 0.36 gave 375 KB, quality 0.48 gave the final 489 KB
Why a third passlanding at 375 KB against a 500 KB ceiling means quality was thrown away for nothing, so one refinement pass climbs back toward the ceiling
What survivespage count, page dimensions in points, page order, and the visual layout exactly as rendered
What does notselectable text, search, internal links, form fields, annotations and screen-reader output — every page becomes one JPEG
Search spaceDPI from 200 down to 40, JPEG quality from 0.85 down to 0.30, five render passes maximum
Convergence modelJPEG bytes are treated as proportional to pixels times quality^0.8, which is what makes two to three passes enough
Already under 500 KBreturned untouched — rasterising a document that already fits would destroy its text for no reason
Honest floorat 40 DPI and quality 0.30 there is nothing left to give; the run is marked amber with the smallest size reached
Input caps100 MB and 150 pages, because every page's pixels pass through this tab's memory
Text-only PDFscompress badly here — a vector text document is already small, and rasterising it usually makes it bigger, not smaller

What happens to your file

Your PDF is never uploaded. pdf.js parses and renders it inside a Web Worker in this tab, the pages are drawn to canvas elements in the same tab, canvas.toBlob encodes each JPEG, and pdf-lib assembles the new document in page memory. The pdf.js worker file is bundled with this site and served from toolchamp.app itself — there is no CDN fetch, no WebAssembly download from a third party, and no API call at any point in the run. The finished document is a blob: URL in this tab and is gone when you close it. Because the whole search happens locally, a five-pass run makes five renders of your document and zero network requests.

About this tool

  1. 1

    Read the warning before you start

    This mode re-renders pages as images. If you need the text in the output to stay selectable or searchable, use the preset-based PDF compressor instead — it is linked in the related tools below.

  2. 2

    Confirm the 500 KB ceiling

    The page opens on 500 KB. The other presets exist because the same loop works at any ceiling, but the numbers on this page were measured at 512,000 bytes.

  3. 3

    Drop in one PDF

    Up to 100 MB and 150 pages. The tool works on a single document at a time because each pass holds a full page of pixels in memory.

  4. 4

    Watch the render passes

    The search log lists each pass with the DPI, the JPEG quality and the resulting file size, so you can see the tool converging rather than guessing.

  5. 5

    Check the verdict

    Green means the achieved size is under 500 KB. Amber means it could not get there, and states the smallest size it managed and what to change.

  6. 6

    Download and open it once

    Scroll the result before you send it. 40 to 150 DPI is fine for reading a scan on screen and marginal for small print, and only your eyes can judge which side your document falls on.

Specs & compatibility
InputPDF only, one file at a time
Size ceiling100 MB — the honest limit for rasterising in a browser tab, not a licensing limit
Page ceiling150 pages
Outputa PDF of the same page count and page dimensions, containing one JPEG per page
Target presets200 KB, 300 KB, 500 KB, 1 MB, 2 MB and 5 MB
Starting settings150 DPI and JPEG quality 0.72 on the first pass
Cancellationa running pass can be cancelled; the partially rendered document is discarded
Browser supportany browser that runs pdf.js 5.x — Chrome, Edge, Firefox, Safari 16.4+
Encryptionpassword-protected PDFs must be unlocked first; pdf.js will not render them
Account or installnone — no signup, no watermark, no page-count paywall
  • Documents that are mostly scans compress dramatically here; documents that are mostly vector text usually get larger, because text is cheaper as glyph instructions than as pixels.
  • If the search log shows the first pass already under 500 KB, your PDF was easy — and if it shows it was already under before any pass, the file was returned untouched.
  • Removing pages you do not need is the single biggest lever: half the pages is roughly half the bytes, with zero quality cost on the pages you keep.
  • A 500 KB ceiling on a 150-page document is about 3.3 KB per page, which no renderer can make legible — split the document instead.
  • Portals that ask for 500 KB usually mean 512,000 bytes, but a few mean 500,000; if a form still rejects the file, set the custom target one preset lower.
  • If you need both a small size and selectable text, extract the text separately and attach it alongside the compressed scan.
  • Iterates to a byte ceiling instead of applying a fixed preset
  • Visible search log of DPI, quality and resulting size per pass
  • Refinement pass so a 500 KB target does not land at 300 KB
  • Original page count and page dimensions preserved exactly
  • Untouched passthrough when the PDF already fits
  • Explicit could-not-reach state with the smallest size achieved
  • Job and visa application portals that reject any attachment over 500 KB.
  • Email systems with a tight per-message limit where several documents must travel together.
  • Uploading scanned receipts or invoices to an expense system with a small per-file cap.
  • Attaching a scanned contract to a ticket or CRM record that caps attachments.
  • Getting a scanned ID document under the limit on a bank or government form.
  • Shrinking a slide deck exported as PDF for distribution over a slow connection.
Because there is no way to hit a hard byte ceiling in a browser without controlling the pixels. The only compression levers a client-side PDF library exposes are the embedded image streams, and reliably rewriting individual image XObjects inside an arbitrary PDF — with its colour spaces, masks, transparency groups and inherited resources intact — is not something pdf-lib can do. Re-rendering each page and re-embedding it as a single JPEG is predictable, works on every PDF, and gives a size that can be measured and iterated on. The trade is that text becomes pixels, which is stated before you press the button rather than discovered afterwards.
Usually two or three, capped at five. The first pass renders at 150 DPI and JPEG quality 0.72. If that overshoots, the next settings are solved from the measured miss using a model where JPEG bytes track pixels multiplied by quality to the power 0.8 — quality is spent first, down to a floor of 0.30, and resolution takes the remainder. If a pass lands well under the ceiling, one refinement pass climbs back up, which is why the measured example ran three times: 837 KB, then 375 KB, then 489 KB.
Your document is probably vector text. A page of text stored as font instructions might be 30 KB; the same page rendered at 150 DPI and stored as a JPEG is several hundred KB, because a photograph of text is far more data than the text itself. The tool checks the original size first and returns the file untouched when it is already under the ceiling, so you should only ever see this if you set a target smaller than a document that was already small. For text documents, the preset-based PDF compressor, which optimises the existing structure, is the right tool.
150 pages, and 100 MB. Both are memory limits rather than policy: each page is rendered into a canvas whose backing bitmap is width times height times four bytes, and a 150 DPI A4 page is about 1240 x 1754 pixels, so roughly 8.7 MB of RAM per page while it is being encoded. The tool frees each canvas as soon as its JPEG is embedded, but a five-pass search on a very long document still asks a lot of a phone. If you are over the limit, split the PDF and compress the parts.
Yes, once the page has loaded. Everything the run needs — pdf.js, its worker, pdf-lib — is served from toolchamp.app as part of the page and then cached by the browser. There is no CDN fetch and no API call during a run, which is different from the video tools on this site, where the ffmpeg WebAssembly core is downloaded from a public CDN on first use. On this page nothing at all leaves the browser.
Not in target-size mode. Each run holds a full page of pixels plus the assembled output document in memory, and does it up to five times, so processing several documents in parallel is the fastest way to run a phone out of memory mid-render. Run them one after another, or use the preset-based PDF compressor, which does support batches because it makes a single pass per file.

Related tools

View all

Updated

We use anonymous analytics to improve ToolChamp. No personal data is stored or sold. Privacy Policy