A PDF has no page size until someone draws one

Open a PDF’s properties and it tells you the page is A4, or Letter, or something odd like 209 × 296 mm. It reads like a property of the document, the way a sheet of paper has a size you could measure with a ruler. It isn’t. A PDF page is a coordinate system with a rectangle drawn around it, and that rectangle is just four numbers stored in the file. Understanding that explains a lot of otherwise baffling behaviour — including why so many attempts to “change the page size” end up with half the text hanging off the edge.

If you just need the practical version, Resize PDF pages handles it. If you want to know what it’s doing under the hood, read on.

The rectangle is called the MediaBox

Every page in a PDF carries a MediaBox: a rectangle given as two corners, in points. A point is 1/72 of an inch, which is why the standard sizes come out as slightly untidy numbers. A4 is 595.28 × 841.89 points. Letter is 612 × 792. Legal is 612 × 1008.

Everything on the page — every glyph, line and image — is placed at coordinates in that same space. A paragraph doesn’t know it’s “near the bottom of an A4 page”. It knows it’s at y = 96. The MediaBox just says where the sheet of paper ends.

That distinction is the whole story.

Why changing the number does nothing useful

If you take a Letter document and rewrite its MediaBox as A4, you haven’t resized anything. You’ve moved the edge of the paper. The content is still sitting at exactly the coordinates it was, so a page that got narrower now has its right margin — and possibly its last column of text — outside the sheet. A page that got taller now has its content bunched at the bottom with a strip of nothing above it.

It’s the difference between shrinking a painting and moving the frame inwards. The frame is cheap to change. The painting isn’t.

This is where a lot of quick page-size hacks go wrong. Text disappears at one edge, content drifts toward a corner instead of centring, and nothing about it is obvious from the file size or the properties panel, because the properties panel is reading the same rectangle you just changed.

What actually resizes a page

The real operation is to draw the page again.

The original page gets packaged up as a reusable drawing — the format’s own mechanism for embedding one page’s content inside another document — and then painted onto a fresh page of the target size, with a scale factor applied. Nothing is edited in place. A new page is composed from the old one.

Two decisions determine what you get:

• Which scale factor. There are two ratios available, width to width and height to height, and they’re rarely equal, because paper standards aren’t the same shape as each other. Taking the smaller of the two scales the content uniformly so it fits inside the new page in both directions, leaving a matched margin on the axis with room to spare. Taking each ratio on its own axis fills the page completely and distorts everything: letters get subtly fat or thin, circles become ovals. Uniform is the sane default; stretching should be something you have to ask for.
• Where to put it. With uniform scaling there’s leftover space on one axis, and it goes on both sides equally. Centring is what makes a converted document look deliberate rather than nudged.

The rotation trap

There’s a second number that makes this harder than it looks. A page can declare a rotation of 90, 180 or 270 degrees separately from its content. The MediaBox still describes an upright rectangle; the viewer applies the rotation when it displays the page.

So a page whose MediaBox says 595 × 842 can be a landscape page on screen, 842 wide and 595 tall. If a resizing routine reads the rectangle and ignores the rotation flag, it computes the scale factors against a width and height that are the wrong way round, and those specific pages come out scaled wrongly while every other page in the document looks fine. It’s the sort of bug that only shows up in documents where someone rotated a scanned page — which is to say, most scanned documents. Handling it means applying the rotation as part of the redraw, not hoping it comes along for the ride. There’s more on how that flag behaves in the piece on rotating pages in a PDF.

Cropping is a third thing entirely

A page can also carry a CropBox, a smaller rectangle inside the MediaBox that says “only show this part”. That’s what most cropping tools change, and it’s the right tool when a scan has huge white borders: the margins stop being displayed, the content keeps its size, nothing is rescaled. Trimming the margins off a PDF is a different job from resizing, and reaching for one when you needed the other is a common way to end up disappointed.

Short version: crop changes what you see of the page. Resize changes how big the page is and rescales what’s on it.

What survives the redraw, and what doesn’t

Because resizing composes new pages rather than editing existing ones, anything that lived alongside the page content rather than inside it is left behind. Annotations go: links, comments, highlights. So do form fields and bookmarks. Document metadata is copied across, and your original file is untouched, so nothing is lost that you can’t go back for.

Worth planning around. If a document is a form you still need to fill in, fill it before you resize. If its bookmarks are the only practical way to navigate 400 pages, weigh that against whatever you were resizing it for.

All of it runs on your machine

None of this needs a server. It’s arithmetic on coordinates and a redraw, and browsers are perfectly capable of both. The resize tool on files.co reads your file into memory on your own device, builds the new document there, and saves it back to you. Nothing is uploaded, which you can confirm with the Network tab in DevTools or by pulling the plug and doing it offline.

Which is how it should be for a document whose page size is the least interesting thing about it.