Passport Photo Size: Why the Print Comes Out Wrong

If you have ever cropped a photo to 35 × 45 mm, sent it to a print shop, and got back something that was not 35 × 45 mm, the crop was almost certainly correct. The problem is that a digital image has no size. It has pixels, and a separate number that says how densely to pack them — and that second number is the one nearly every guide leaves out, because it is invisible in every photo editor you will use.

This post is about the second number. Everything below was measured by running a passport photo tool on a real 1600 × 2133 photograph and then reading the bytes of the file it produced, rather than reading the result the page displayed.

Two things have to be right, and guides only mention one

A passport photo has to satisfy two independent facts:

• How many pixels it has. 35 mm at 300 dots per inch is 413 px. This is the part every guide covers, and it is arithmetic.
• How many of those pixels go into an inch. This is stored in the file itself, in a small header block that most tools never write.

Get the first right and the second wrong and you have a file that looks perfect on screen, measures correctly in any image editor, and prints at whatever size the printer driver felt like using.

What the file actually says

A JPEG can begin with a JFIF segment, a 18-byte block that carries the image’s resolution. Here are the first twenty bytes of a JPEG produced by Chrome’s own canvas, which is what a browser-based converter uses to write your download:

ff d8 ff e0 00 10 4a 46 49 46 00 01 01 00 00 01 00 01 00 00
            J  F  I  F  \0  v1.01  ^  ^^^^^  ^^^^^
                                  |    |      |
                          units=0  X=1    Y=1

Read the three fields that matter. Units is 0, and the JFIF specification defines 0 as “no units, aspect ratio only” — the density fields are not dots per inch at all. X and Y density are both 1. So the file does not say “300 dpi”, or “72 dpi”, or anything in between. It says nothing, twice, in a field that exists to say something.

This is not a bug in Chrome. The canvas API takes a MIME type and a quality, and has no parameter for resolution, so there is nowhere for a caller to pass one. A tool that computes 413 × 531 px correctly, encodes the crop, and hands you the blob has done exactly what the platform allows — and the file still has no physical size. Writing one means editing the header bytes after the encode, which is a different kind of work from drawing to a canvas.

What that does on paper

The consequence is pure division. A 413-pixel-wide image printed at 300 dpi occupies 413 ÷ 300 = 1.377 inches, which is 35.0 mm. The same 413 pixels printed at 72 dpi occupies 5.74 inches, which is 145.7 mm:

• 413 × 531 px at 300 dpi → 34.97 × 44.96 mm. The document size you asked for.
• 413 × 531 px at 72 dpi → 145.7 × 187.3 mm. A postcard.
• 413 × 531 px with no density at all → whatever the printer’s default is, which on most systems is 72 dpi, and on some is the paper width.

That last line is the one that bites. Nothing errors. Nothing warns. The photo is the right shape, the file is the right pixel count, and the print is four times too wide.

How to check your own file before you print it

You do not have to guess, and you do not need a special tool. The resolution is in the file, so anything that reads metadata can show it.

On macOS, in Terminal:

sips -g dpiWidth -g dpiHeight your-photo.jpg

A file with no resolution reports dpiWidth: 72.000 and dpiHeight: 72.000 — 72 is what the tool prints when the field is absent, which is why 72 is the number you should be suspicious of. A correctly tagged passport photo reports 300.

On Linux, with ImageMagick installed:

identify -format "%x x %y %U\n" your-photo.jpg

On Windows, right-click the file, choose Properties, and open the Details tab. The field is called Horizontal resolution and Vertical resolution, and it is shown in dpi. If it says 72, or if the row is missing entirely, the file has no usable physical size.

If you get 72, the fix is not to re-crop. Set the resolution and the pixel count together, in one tool, and check the number again afterwards.

The pixel counts, for the sizes people actually need

Every figure below is millimetres ÷ 25.4 × resolution, rounded to the nearest pixel, and every one of them was produced by the tool and confirmed by reopening the output with an independent decoder:

Size	At 300 dpi	At 600 dpi
35 × 45 mm	413 × 531 px	827 × 1063 px
2 × 2 in (50.8 mm square)	600 × 600 px	1200 × 1200 px
51 × 51 mm	602 × 602 px	1205 × 1205 px
33 × 48 mm	390 × 567 px	780 × 1134 px
50 × 70 mm	591 × 827 px	1181 × 1654 px
35 × 50 mm	413 × 591 px	827 × 1181 px

Note that 51 mm at 600 dpi is 1205, not 1204. 51 ÷ 25.4 × 600 is 1204.72. A tool that rounds to a tidy even number has moved the edge of your photo by 0.03 mm, which does not matter — but it tells you whether the tool computed the number or copied it from a table.

The other half nobody measures: head height

Size and resolution get you a correctly shaped rectangle. They do not get you a photo that passes, because the requirement that actually rejects applications is how big the head is inside that rectangle.

GOV.UK states it plainly for printed UK passport photos: the image of you, from the crown of your head to your chin, must be between 29 mm and 34 mm high on a 45 mm photo. That is a band 11.1% of the frame’s height, sitting between 24.4% and 35.6% of the way down from the top. Measured on the rendered page, the guide band came out at 41.3 px of a 372 px frame — 11.11% — which is the arithmetic agreeing with itself.

Here is the part worth understanding. That rule is stated for a 45 mm photo. Apply the same 29–34 mm band to a 50.8 mm (2 × 2 in) photo and it covers 9.86% of the frame instead of 11.11%, in a different position — so a tool that offers one head band and a country list is quietly giving you the wrong guide for most of the list. It is the same class of error as a file tagged 1 dpi: the number is present, it is just not the number for your case.

This is why the tool offers exactly one head rule, by name, with its source quoted underneath, and says so in amber when you pair it with a photo height it was not written for.

What the tool produced on a real photograph

The source was a real 1600 × 2133 photograph of 307,142 bytes. Every output below was downloaded from the running page, then reopened with ImageMagick for its dimensions and parsed by hand for its JFIF fields:

• 35 × 45 mm at 300 dpi → 413 × 531 px, 41,470 bytes, header units 1, X = Y = 300.
• The same crop at 600 dpi → 827 × 1063 px, 161,709 bytes, header units 1, X = Y = 600.
• 2 × 2 in at 300 dpi → 600 × 600 px, 62,468 bytes, units 1, 300 dpi.
• 51 × 51 mm at 300 dpi → 602 × 602 px, 63,342 bytes, units 1, 300 dpi.
• The 4 × 6 in print sheet → 1200 × 1800 px, 149,387 bytes, units 1, 300 dpi, six copies of the 35 × 45 mm photo.

The control matters as much as the results. The same browser, in the same session, writing a plain canvas JPEG with no header rewrite, produced units 0 and density 1 — so the 300 in those five lines is something the tool did, not something the platform does.

One detail worth knowing before you pick 600 dpi: the 600 dpi file is four times the bytes because it has four times the pixels. That is only a real improvement if your source photo has the pixels to fill 827 × 1063. From a 1600 × 2133 photograph it does. From a 600 × 800 crop it does not, and the tool says so on the result line — upscaled ×1.7 from 240 × 309 px — instead of handing you a soft print with a confident label on it.

Where it refuses, and why that is the feature

Three inputs do not get a file back:

• A file that is not an image. A text file renamed .jpg is refused by name: the browser could not decode it, and it may be corrupt, truncated or in a format the browser cannot read. No blob: URL is ever shown, because that names something you cannot see.
• An image that lost its end. A PNG cut off mid-download still decodes in Chrome — the decoder renders the scanlines it has and reports success — so converting it would produce a mostly-blank photo. The container’s own end marker is checked, and a truncated file is refused.
• An empty selection. A crop smaller than a pixel is a bug, not a photo.

An input that is merely small is not refused. It is labelled. That is the right split: you may have no other photograph of yourself, and a soft print is better than no application — but you should be told which one you are getting.

What this does not do

It does not judge whether your photo will be accepted. Expression, shadows on the face or the background, glasses, head coverings, red eye, print sharpness, and whether the background is the shade your document demands are all reasons real applications get rejected, and none of them can be assessed from geometry. A tool that stamps “compliant” on a photo it has not looked at is worse than one that stays quiet about it.

What it does is the part that is checkable: the size, the pixel count, the resolution written into the file, the head band for the one document whose rule could be read and quoted, and a print sheet with the copies already at their true physical size.

Nothing is uploaded

A passport photo is a photograph of your face attached to your identity, which makes it the single worst file to send to a server you cannot inspect. The decode, the crop, the encode and the header rewrite all run in your browser, and there is no network request after the page loads.

You can prove it the same way you prove anything else here: load the page, disconnect from the internet, and make the photo. It still works, because nothing was ever being sent anywhere.

The short version

413 × 531 px is the right answer for 35 × 45 mm at 300 dpi, and it is only half the job. The other half is the resolution field in the file, which a browser canvas leaves at 1 dpi with no unit — so check it with sips or the Windows Details tab before you pay for a print. If it says 72, the crop was fine and the header was not.