DEV Community: Jason T.

Can you reuse a passport photo? The rules for 21 documents

Jason T. — Thu, 08 Oct 2026 16:05:01 +0000

You can reuse a passport photo if it passes four checks for the new application: digital versus paper, photo age, dimensions and head ratio, and background colour. Start with the 21-document requirements table and its official source links.

Some failures can be fixed by resizing or recompressing; others cannot. A crop that is too tight needs the original, wider image.

Do you need a digital file or a paper photo?

Check what the application accepts before editing your photo.

DS-160 and Thailand e-Visa require a digital file. A print works only where paper photos are accepted. If you have the original digital photo from your studio or booth, start there.

These documents have restrictions on scans or photos of photos:

Document	Restriction
US passport	No photocopies or digitally scanned photos
New Zealand passport	Scans of printed photos are not accepted
UK visa	Not a scan or photo of another photo
NZeTA	Not a photo of a photo

For the UK visa, there is a further restriction: you cannot use the same photo that is in your passport or identity card.

Before working on upload limits, establish whether you have an acceptable source image.

Is your passport photo still recent enough?

Check the photo age requirement for your document.

Document	Photo age requirement
US passport	Taken in the last 6 months
New Zealand passport	Less than 6 months old
NZeTA	Less than 6 months old
Pakistan visa	No more than 6 months old
Ethiopia e-Visa	Taken within the last six months

Look up these requirements and their official sources.

What dimensions and head size does your application require?

Check shape, dimensions, file size and framing separately.

"Passport size" is too vague for this decision. Use the requirements for the document you are applying for:

Document	Dimensions and format	File size	Head size
India e-Visa	Square JPEG	10 KB–1 MB
OCI	Square JPEG, 200×200 to 900×900 px	Maximum 200 KB
DS-160	Square, 600×600 to 1200×1200 px	Maximum 240 KB	50–69% of image height
Schengen	35×45 mm		70–80% (32–36 mm)
UK visa/ETA	At least 600×750 px, JPG	50 KB–6 MB

Find the document rows and official source links for these numerical requirements.

For DS-160, a square file must also pass the pixel range, maximum file size and head-height check.

Keep the units separate, too. Schengen's 35×45 mm describes print dimensions. DS-160's dimensions are in pixels.

Resizing and reframing solve different problems. If your head occupies 73% of the image height, it exceeds DS-160's 69% maximum.

You need the original, wider photo to make a suitable crop.

Does your existing background colour work?

Compare the background with the destination document's rule.

Document	Background requirement
OCI	Plain light-coloured, not white
Australia visa	Plain neutral or light grey
Vietnam e-Visa	White

Check the document requirements and their official sources.

A typical white-background passport photo fails OCI's background requirement.

Vietnam e-Visa requires white.

What can a JavaScript validator actually check?

You can automate the square and byte-window checks. This function takes width, height and file size in bytes, then checks India's square requirement and a 10 KB–1 MB window.

The implementation uses decimal units: 1 KB is 1,000 bytes and 1 MB is 1,000,000 bytes. That is an explicit code convention, not an additional photo requirement.

function checkIndiaPhotoBasics(width, height, fileSizeBytes) {
  const validDimensions =
    Number.isInteger(width) &&
    Number.isInteger(height) &&
    width > 0 &&
    height > 0;

  const square = validDimensions && width === height;

  // Decimal-unit convention for this validator.
  const minBytes = 10 * 1000;
  const maxBytes = 1000 * 1000;

  const sizeInRange =
    Number.isInteger(fileSizeBytes) &&
    fileSizeBytes >= minBytes &&
    fileSizeBytes <= maxBytes;

  return {
    square,
    sizeInRange,
    passesBasicChecks: square && sizeInRange
  };
}

The function deliberately returns passesBasicChecks, not validPassportPhoto.

Which edge cases can still rule out reuse?

Before submitting, watch for these exceptions:

UK visa: The photo must not be a scan or photo of another photo, or the same photo that is in your passport or identity card.

DS-160: A tightly cropped photo with a head height of 73% exceeds the 69% maximum and needs the original, wider photo. Return to the wider original rather than repeatedly resizing the crop.

A white background can be the wrong background. For OCI, check "not white" before spending time adjusting file size.

Meeting the rules does not guarantee acceptance.

Where can you look up all 21 documents?

Keep the 21-document requirements table beside your application.

For more help deciding whether to reuse your file, use the existing-passport-photo guide. You can also use the free photo checker before paying.

Disclosure: I built pixtidy.

Convert photo sizes from millimetres to pixels without mixing up upload rules

Jason T. — Wed, 07 Oct 2026 16:05:01 +0000

China's 33 × 48 mm paper photo converts to 390 × 567 px at 300 dpi. Its separate digital upload rule is 354 × 472 to 420 × 560 px. Use Math.round(mm / 25.4 * dpi) for print conversions. Validate upload dimensions and head height against their own rules.

The official print and pixel sizes for all 21 documents are in pixtidy's requirements table (disclosure: I built it).

How do you convert millimetres to pixels in JavaScript?

Pass the physical measurement and dpi explicitly.

function mmToPixels(mm, dpi) {
  return Math.round(mm / 25.4 * dpi);
}

mmToPixels(33, 300); // 390
mmToPixels(48, 300); // 567

Apply the function independently to width and height. Round at the end, not during the division.

Keep this function narrow. Giving it file-format or head-height logic would hide which requirement you are actually testing.

Calculate each resolution from the original millimetres. Schengen's 35 mm width rounds to 413 px at 300 dpi, but doubling that rounded result gives 826 px. Converting 35 mm directly at 600 dpi gives 827 px.

That one-pixel difference is a useful regression test for code that generates multiple print resolutions.

What sizes should your conversion tests expect?

Keep the physical input beside each expected result.

Print photo	Physical size	Dpi	Converted size
Schengen visa	35 × 45 mm	300	413 × 531 px
Schengen visa	35 × 45 mm	600	827 × 1063 px
US passport	2 × 2 in	300	600 × 600 px
US passport	2 × 2 in	600	1200 × 1200 px
Chinese visa	33 × 48 mm	300	390 × 567 px

Use the millimetre rows as fixtures for mmToPixels. The US passport print size is specified in inches: 2 × 2 in.

The DS-160 digital rule also uses 600 × 600 to 1200 × 1200 px. Store those as direct pixel constraints, independently of the US passport print calculation.

How should you model print, upload, and head-height requirements?

Give each requirement its own scope and unit.

A compact model can preserve the original measurements without turning every rule into pixels up front:

const requirements = {
  chinaVisa: {
    print: { unit: "mm", width: 33, height: 48 },
    upload: {
      widthPx: [354, 420],
      heightPx: [472, 560],
      format: "JPEG",
      sizeKB: [40, 120]
    },
    head: { scope: "print", unit: "mm", range: [28, 33] }
  },
  schengenVisa: {
    print: { unit: "mm", width: 35, height: 45 },
    head: {
      scope: "print",
      unit: "mm",
      range: [32, 36],
      measurement: "chin-to-crown"
    }
  },
  usPassport: {
    print: { unit: "in", width: 2, height: 2 }
  },
  ds160: {
    upload: {
      widthPx: [600, 1200],
      heightPx: [600, 1200],
      square: true,
      sizeKB: [null, 240]
    },
    head: {
      scope: "digital",
      unit: "percent",
      range: [50, 69]
    }
  }
};

The DS-160 file-size rule is 240 KB or less. China's digital file-size rule is 40–120 KB.

The conversion formula takes dpi as an input. That lets you generate Schengen output at 300 or 600 dpi from the same physical dimensions.

The scope field matters for China's head-height requirement. Its 28–33 mm measurement belongs to the 48 mm paper photo.

How can you validate digital dimensions and file limits?

Return individual failures instead of a single unexplained boolean.

This validator takes normalized metadata. sizeKB is already expressed in KB, and format uses the model's "JPEG" label.

function validateUpload(rule, photo) {
  const errors = [];
  const within = (value, [min, max]) =>
    (min === null || value >= min) && value <= max;

  if (!within(photo.widthPx, rule.widthPx)) {
    errors.push("width");
  }
  if (!within(photo.heightPx, rule.heightPx)) {
    errors.push("height");
  }
  if (rule.square && photo.widthPx !== photo.heightPx) {
    errors.push("square");
  }
  if (rule.format && photo.format !== rule.format) {
    errors.push("format");
  }
  if (!within(photo.sizeKB, rule.sizeKB)) {
    errors.push("file-size");
  }

  return errors;
}

China's upload limits are 354 × 472 to 420 × 560 px, JPEG, and 40–120 KB. The 300 dpi print size is separate from the digital upload size.

DS-160 has a 240 KB ceiling.

Treat these results as metadata checks, not a promise of acceptance. Head height still needs its own measurement.

Which boundary tests catch the China mismatch?

Test rejected inputs as well as the exact allowed boundaries.

Run this after the function and model above. Each test throws if the validator returns an unexpected result.

function expectErrors(name, rule, photo, expected) {
  const actual = validateUpload(rule, photo);
  if (JSON.stringify(actual) !== JSON.stringify(expected)) {
    throw new Error(`${name}: got ${JSON.stringify(actual)}`);
  }
}

const china = requirements.chinaVisa.upload;
const base = {
  widthPx: 390,
  heightPx: 560,
  format: "JPEG",
  sizeKB: 40
};

const cases = [
  ["minimum dimensions", { widthPx: 354, heightPx: 472 }, []],
  ["maximum dimensions", { widthPx: 420, heightPx: 560 }, []],
  ["width below minimum", { widthPx: 353 }, ["width"]],
  ["width above maximum", { widthPx: 421 }, ["width"]],
  ["height below minimum", { heightPx: 471 }, ["height"]],
  ["height above maximum", { heightPx: 561 }, ["height"]],
  ["print conversion", {
    widthPx: mmToPixels(33, 300),
    heightPx: mmToPixels(48, 300)
  }, ["height"]],
  ["below 40 KB", { sizeKB: 39 }, ["file-size"]],
  ["at 40 KB", { sizeKB: 40 }, []],
  ["at 120 KB", { sizeKB: 120 }, []],
  ["above 120 KB", { sizeKB: 121 }, ["file-size"]],
  ["wrong format", { format: "PNG" }, ["format"]]
];

for (const [name, patch, expected] of cases) {
  expectErrors(name, china, { ...base, ...patch }, expected);
}

const ds160 = requirements.ds160.upload;
for (const [sizeKB, expected] of [
  [240, []],
  [241, ["file-size"]]
]) {
  expectErrors(`DS-160 ${sizeKB} KB`, ds160, {
    widthPx: 600,
    heightPx: 600,
    sizeKB
  }, expected);
}

These tests make the inclusive boundaries visible.

Keep the print-conversion case even if you already test 561 px. It catches a different implementation mistake: populating upload dimensions from a correct print calculation.

How do you test head height without mixing units?

Schengen specifies head height in millimetres; DS-160 specifies a percentage of image height.

For Schengen, chin-to-crown height is 32–36 mm. At 300 dpi, the rounded range is 378–425 px.

DS-160 instead requires 50–69% of image height:

const schengenHead300 =
  requirements.schengenVisa.head.range.map(
    mm => mmToPixels(mm, 300)
  ); // [378, 425]

function ds160HeadPasses(headPx, imageHeightPx) {
  const percent = headPx / imageHeightPx * 100;
  const [min, max] = requirements.ds160.head.range;
  return percent >= min && percent <= max;
}

China's JPEG requirement and both file-size bounds remain separate.

Head-height numbers need units and scope. Schengen's range is 32–36 mm, while DS-160's range is 50–69% of image height.

Where can you find document-specific official sources?

Review the document's source before updating its fixture.

pixtidy's requirements table lists print sizes, digital file rules, head height, and official-source links for 21 documents.

Use the relevant document's official-source link when reviewing a change. Then update the matching model field and its boundary tests.

Disclosure: I built pixtidy.

How I built pixtidy's browser layout for six 2 2-inch green card photos on a 4 6 print

Jason T. — Tue, 06 Oct 2026 16:05:01 +0000

USCIS asks for two identical colour 2×2-inch photos. I built pixtidy's browser layout to fit six on one 4×6-inch print: an 1800×1200-pixel sheet at 300 dpi. Below, I explain the layout function and how to draw the sheet on a canvas for JPEG export. Print at actual size to preserve the dimensions.

You can check your own photo against these rules for free in your browser on this page; the photo is never uploaded (disclosure: I built it).

What are the USCIS green card photo requirements?

Start with a photo that meets the requirements before you repeat it.

You need two identical colour passport-style photos taken recently, each:

2×2 inches.
Printed on thin paper with a glossy finish.
Unmounted and unretouched.
Taken against a white to off-white background.

The head, measured from the top of the hair to the bottom of the chin, must be 1 to 1⅜ inches. The eyes must be 1⅛ to 1⅜ inches from the bottom of the photo.

Lightly print your name and A-Number, if any, on the back with a pencil or felt pen. The same photos are used for Forms I-485, I-765 and I-131.

Meeting the rules does not guarantee acceptance.

How do six 2×2-inch photos fit on a 4×6-inch print?

1. Use a horizontal sheet with no space between photos.

At 300 dpi, the dimensions are:

Item	Printed dimensions	Pixel dimensions
Sheet	6 inches wide × 4 inches high	1800×1200
Each photo	2 inches wide × 2 inches high	600×600

Three photos fill the width, and two fill the height. One print therefore gives you the required pair and four spares.

The layout function calculates the columns and rows with:

columns = floor((sheet width + gap) / (photo width + gap))
rows    = floor((sheet height + gap) / (photo height + gap))

For this sheet, gapPx = 0, so the result is three columns and two rows. The grid fills the canvas, and its centred starting position is (0, 0).

Top-left coordinates, in pixels:

(0, 0)       (600, 0)       (1200, 0)
(0, 600)     (600, 600)     (1200, 600)

The internal cut boundaries sit at x = 600, x = 1200 and y = 600.

How does the layout function work?

2. Calculate the slots for six copies of the photo.

This is my layout function from web/src/lib/photo/sheet.ts. It calculates how many photos fit and centres the resulting grid on the sheet.

export function layoutSheet(sheet, photo, gapPx = 0) {
  const cols = Math.floor((sheet.widthPx + gapPx) / (photo.widthPx + gapPx));
  const rows = Math.floor((sheet.heightPx + gapPx) / (photo.heightPx + gapPx));
  const gridW = cols * photo.widthPx + (cols - 1) * gapPx;
  const gridH = rows * photo.heightPx + (rows - 1) * gapPx;
  const x0 = (sheet.widthPx - gridW) / 2, y0 = (sheet.heightPx - gridH) / 2;
  const slots = [];
  for (let r = 0; r < rows; r++) for (let c = 0; c < cols; c++)
    slots.push({ x: x0 + c * (photo.widthPx + gapPx), y: y0 + r * (photo.heightPx + gapPx) });
  return slots;
}

For the worked example, the sheet dimensions are 1800×1200, the photo dimensions are 600×600, and the gap is 0. The function returns the six positions shown above.

How do you draw the sheet on a canvas?

3. Fill the canvas white, then draw the same photo in each slot.

Use an 1800×1200-pixel canvas for the sheet. After filling it white, call drawImage for each returned slot, drawing the same photo at 600×600 pixels.

The arrangement is:

                  6 inches
        ┌─────────┬─────────┬─────────┐
        │         │         │         │
        │  Same   │  Same   │  Same   │
        │  photo  │  photo  │  photo  │
        │         │         │         │
4 inches├─────────┼─────────┼─────────┤
        │         │         │         │
        │  Same   │  Same   │  Same   │
        │  photo  │  photo  │  photo  │
        │         │         │         │
        └─────────┴─────────┴─────────┘
             Each cell: 2×2 inches

The 1-pixel light-grey cut guides are my design choice, not a USCIS rule. Draw them on the canvas before exporting the sheet as a JPEG so they appear in the exported image.

How do you print the JPEG at the correct size?

4. Export the JPEG and set its physical print size explicitly.

Use this compact checklist:

[ ] Print the sheet 6 inches wide × 4 inches high.
[ ] Turn off "fit to page" scaling.
[ ] Use thin paper with a glossy finish.
[ ] Check that each printed photo measures 2×2 inches before using it.

The intended conversion is 600 pixels ÷ 300 pixels per inch = 2 inches. The export provides the pixels; the print settings must preserve that physical relationship.

Which edge cases need a separate check?

The layout function accepts a gap. The zero-gap grid already occupies the entire sheet.

Check the photo requirements before making the sheet.

Where can you use pixtidy's green card photo tools?

You can use pixtidy's green card photo page for the green card workflow and pixtidy's photo requirements page to review the requirements.

Disclosure: I built pixtidy.

ChatGPT sent French users to our English page: what we changed

Jason T. — Mon, 05 Oct 2026 16:05:00 +0000

Two ChatGPT-tagged visits from France exposed a missing French Thailand e-Visa photo page. We added that page, localized links in llms.txt, and a hydration-safe browser-language hint.

What did the French visits actually tell us?

On 2026-10-03, two visitors reached pixtidy's English Thailand e-Visa photo page with utm_source=chatgpt.com. Earlier that evening, a third French visitor had reached the same page.

At first, our analytics obscured this. PostHog's own GeoIP located our forwarding server in Ashburn, Virginia, producing a country breakdown that said "almost all US." That was the server's location, not a useful account of our audience.

The country from the request header on our own event endpoint placed these visitors in France.

That gave us a concrete gap to investigate: we had an English Thailand page and no French equivalent. Country helped expose the missing page; browser-language preferences would decide whether to offer its link.

What should you change when a localized page is missing?

We added the missing French page.

We added the French Thailand e-Visa photo page at /fr/photo-evisa-thailande.

A writing tool drafted the copy, and a second model reviewed it. One required correction: the lead repeated the meta description word for word. We removed that repetition.

The page's reviewed title also became the text for the language hint. That kept the hint tied to the actual destination rather than introducing a separate, unreviewed translation.

Connect the localized page to the document listing.

Each document line in our llms.txt now ends with an Also in: suffix listing localized pages.

For the Thailand line, the compact before-and-after is:

Before: no French-page suffix.
After: an Also in: suffix linking to the French page.

That shows the added relationship without reproducing the rest of the document line. A unit test checks that the Thailand line links to the French page.

This test answers a narrow question: did we retain the link?

Offer a link beneath the English page's H1.

English document pages now read navigator.languages. If the first non-English language ranks above English and the corresponding page exists, the hint appears.

In our browser checks, French showed the link and English showed nothing.

How do you wire the hint with useSyncExternalStore?

Our implementation uses useSyncExternalStore so the server-rendered hint stays empty, with no hydration mismatch.

Here is simplified wiring that includes the language selection, server snapshot, and destination check. The pages prop represents the current document's localized destinations, keyed by language, with each destination's href and reviewed title.

import { useSyncExternalStore } from "react";

const subscribe = () => () => {};
const getServerSnapshot = () => null;

function getSnapshot() {
  const codes = navigator.languages.map((tag) =>
    tag.toLowerCase().split("-")[0]
  );
  const other = codes.findIndex((code) => code !== "en");
  const english = codes.indexOf("en");

  return other !== -1 && (english === -1 || other < english)
    ? codes[other]
    : null;
}

export function LanguageHint({ pages }) {
  const language = useSyncExternalStore(
    subscribe,
    getSnapshot,
    getServerSnapshot
  );
  const page = language ? pages[language] : null;

  return page ? <a href={page.href}>{page.title}</a> : null;
}

Render this component beneath the English document's H1.

The important boundary is getServerSnapshot. The browser snapshot then supplies the preferred language candidate.

The snapshot returns a language string or null, rather than a newly created object. The destination lookup happens afterward, so language preference and page availability remain separate decisions.

The subscription in this simplified example is deliberately a no-op.

Which language-selection edge cases should you check?

English comes first. If French appears below English in navigator.languages, this rule shows no French hint. Being present in the list is not enough. The first non-English language must rank above English.

The preferred translation does not exist. The code selects the first non-English language, then checks for that page. It does not scan through less-preferred languages until it finds a translation. A missing destination means no hint.

English is absent. It still needs a matching localized page.

These cases define what the hint does.

Did the Thailand answer cite the French page afterward?

The 2026-10-04 weekly check did not. The Thailand question cited no site at all, as did the new UK ETA question.

Our weekly script asks ChatGPT 18 real questions with web search on. In that run, pixtidy appeared in 1 of 18 answers. The mention was for a Chinese visa photo question, citing pixtidy.com/china-visa-photo alongside two other tools.

For the next weekly comparison, the useful reporting questions are specific: how many of the 18 answers mention pixtidy, whether the Thailand answer cites the French page, and whether French-page arrivals carry the ChatGPT tag.

There was another problem after arrival. All three French visitors uploaded a photo, and all failed "Whole head fits in the frame." That was a separate cropping bug, fixed the next day and covered in another post.

Disclosure: I built pixtidy.

Why a ready-made ID photo failed our browser framing check

Jason T. — Sun, 04 Oct 2026 16:05:00 +0000

Treat head centring as a preference: clamp the crop to valid bounds, then test against the rotated image. That fixed our framing bug. A −1.1° rotation left roughly 10 px of blank space at the top corners of a 538 px-wide crop.

You can check your own photo against these rules for free in your browser on this page; the photo is never uploaded (disclosure: I built it).

Why did ready-made ID photos fail?

When I reviewed analytics on October 3–4, 2026, five people had uploaded a photo during the week. All five saw "likely to be rejected".

Three uploads, all on the Thailand e-Visa page, failed only "Whole head fits in the frame". Their background statistics, mean 254 and standard deviation 6, suggested ready-made studio ID photos with white backgrounds. That was a clue, not proof of where the photos came from.

pixtidy crops photos in the browser to an official spec. Our placement code had two problems: it treated vertical centring as mandatory, then treated the canvas boundary as the image boundary.

A tightly cropped photo exposed both.

How do you keep the whole head inside the crop?

Separate the required head ratio from your preferred placement.

Thailand e-Visa photos require a head ratio of 70–80%, JPG up to 3 MB, and a height of at least 160 px. There is no published crown-margin or eye-line rule, so our code centred the head vertically.

At a preferred 75% head ratio, that centred crop could extend above the image. Studio ID photos often leave little space above the head. Rejecting the centred placement without trying another allowed position was the first bug.

Calculate the allowed interval, then clamp your preference.

For crop height H, keeping the crown and chin inside requires:

   y <= crownY
   y >= chinY - H

These give you lo and hi. Intersect them with any crown-margin or eye-line ranges required by the spec. Then intersect with the image bounds:

   function clampTop(
     preferredY: number,
     lo: number,
     hi: number,
     imageHeight: number,
     H: number,
   ): number | undefined {
     const lower = Math.max(lo, 0);
     const upper = Math.min(hi, imageHeight - H);
     if (lower > upper) return undefined;
     return Math.max(lower, Math.min(preferredY, upper));
   }

What does the rotated-image containment test check?

Test the complete crop against actual image coverage.

Local measurements showed that the photo had been rotated by −1.1° to make the eyes level. Rotation left blank canvas corners. The first fix could put the crop at y = 0, inside the canvas rectangle but outside the real image.

For a 538 px-wide crop, the corner loss was roughly:

   538 × sin(1.1°) ≈ 10 px

The head bounds constrain where you may place the crop. The rotated-image boundary decides whether image content covers that entire crop.

Why try 41 positions, and can the scan miss a fit?

Search within the allowed interval when the clamped candidate fails.

The second fix tries 41 positions across [lo, hi], nearest to the preferred position first, and keeps the first that passes the rotated-image test.

Here, lo and hi already include the intersections above:

   function scanTop(
     lo: number,
     hi: number,
     preferredY: number,
     insideRotatedImage: (y: number) => boolean,
   ): number | undefined {
     if (lo > hi) return undefined;

     const positions = Array.from(
       { length: 41 },
       (_, i) => lo + ((hi - lo) * i) / 40,
     );
     positions.sort(
       (a, b) => Math.abs(a - preferredY) - Math.abs(b - preferredY),
     );
     return positions.find(insideRotatedImage);
   }

The measured test photo passed after the fix.

What changed in the live tool?

Compare the same photo before and after, and preserve legitimate failures.

The live-tool test used a tightly cropped 568×757 photo with the head at 72%. Before the fix, framing failed. Afterward, it passed the Thailand e-Visa framing check.

It still failed the US visa framing check, correctly. The US range is 50–69%, and the head already occupied 72% of the photo.

Face measurements are not sent to analytics. I investigated with a console.log behind a window flag in a local development build, then removed it.

Two new unit tests were added: a tightly cropped photo, and a tilted photo with a custom in-bounds predicate. The existing "face far off-centre stays out of bounds" test still passes. The suite totals 363 tests.

Which edge cases should you keep testing?

Tight top margins: move the crop within the allowed interval before rejecting a preferred position.

Rotated corners: a canvas-bounded crop can still contain blank space. Test actual image coverage.

Incompatible framing: keep the 72% head failing under the US rule, and preserve the far-off-centre regression.

A tool's framing pass does not promise official acceptance.

Disclosure: I built pixtidy.

Schengen visa photos are 35 45 mm: turning millimetre rules into browser checks

Jason T. — Sat, 03 Oct 2026 16:18:58 +0000

Schengen requires a 35×45 mm paper photo, with a 32–36 mm chin-to-crown span. At pixtidy's chosen 600 dpi, the export is 827×1063 pixels. The head-height calculation below uses annotated chin and crown coordinates. There is no common Schengen digital-upload specification.

Update, 5 October 2026: consulate checklists in the US can differ from 35 × 45 mm. Spain's Consulate General in Chicago asks for photos of approximately 2 × 2 inches, and the Embassy of Switzerland in the USA accepts 35 × 45 mm or a US standard-sized passport photo. Check the checklist of the consulate where you apply before printing.

You can check your own photo against these rules for free in your browser on this page; the photo is never uploaded (disclosure: I built it).

What measurements should you start with?

Keep the paper size and head size as separate inputs.

I built pixtidy, whose free check uses MediaPipe face detection in your browser. Your photo is never uploaded. The useful engineering question is how to connect physical photo rules to measurements you can actually test.

Start with the European Commission ICAO photo guidelines and German Foreign Office visa photo instructions.

For the geometry, keep these values explicit:

const photoWidthMm = 35;
const photoHeightMm = 45;
const minHeadHeightMm = 32;
const maxHeadHeightMm = 36;

The first two describe the finished paper photo. The last two describe the chin-to-crown span within it.

How do you convert 35×45 mm to pixels at 600 dpi?

Apply the export resolution to each paper dimension.

Use millimetres divided by 25.4, then multiply by the resolution in dots per inch:

const dpi = 600;
const mmToPx = mm => Math.round(mm * dpi / 25.4);

const widthPx = mmToPx(photoWidthMm);   // 827
const heightPx = mmToPx(photoHeightMm); // 1063

The calculations are:

Width:  35 × 600 / 25.4 ≈ 827 pixels
Height: 45 × 600 / 25.4 ≈ 1063 pixels

That is pixtidy's 827×1063-pixel export at 600 dpi. The rounding gives you whole-pixel image dimensions.

I would label this in an interface as "600 dpi export dimensions." There is no common Schengen digital-upload specification.

How do you obtain a chin-to-crown measurement?

Make the measurement endpoints explicit before checking the range.

MediaPipe face detection is the detection step in pixtidy. For this walkthrough, I would use manual annotation for the chin-to-crown measurement: display the photo and ask you to mark the crown and chin. This is a proposed measurement workflow, not a claim that pixtidy provides an annotation feature.

The annotations would look like this:

Top of photo
┌─────────────────────────┐
│                         │
│   Crown ───────── yCrown│
│          ↕              │
│      Measured span      │
│          ↕              │
│   Chin ────────── yChin │
│                         │
└─────────────────────────┘
Bottom of photo

With vertical coordinates increasing down the image, subtract the crown coordinate from the chin coordinate:

const headHeightPx = yChin - yCrown;

The important work happens before that subtraction. In this workflow, you identify the endpoints on the photo.

If annotations are made on a scaled browser preview, convert the span to export coordinates:

const exportHeadHeightPx =
  (previewChinY - previewCrownY) *
  heightPx / previewHeightPx;

This gives you a concrete way to convert the annotated span into export pixels.

What does a worked head-height check look like?

Calculate proportional bounds, then test the annotated span.

The head-height rule is 32–36 mm within a 45 mm-high photo. As a fraction of image height, that is approximately 71–80%.

Keep the original fractions in code:

const minHeadPx = heightPx * minHeadHeightMm / photoHeightMm;
const maxHeadPx = heightPx * maxHeadHeightMm / photoHeightMm;

// minHeadPx ≈ 755.91
// maxHeadPx = 850.4

For a worked boundary example, take an annotated span of 850 pixels, the whole-pixel value just below the calculated upper bound. This is an arithmetic example, not a measurement from a real applicant's photo.

const measuredHeadPx = Math.floor(maxHeadPx); // 850

const withinHeadHeightRange =
  measuredHeadPx >= minHeadPx &&
  measuredHeadPx <= maxHeadPx;

const equivalentHeadMm =
  measuredHeadPx / heightPx * photoHeightMm;

// withinHeadHeightRange: true
// equivalentHeadMm: approximately 35.98

The annotated distance passes because 850 is above approximately 755.91 and below 850.4. Translated back into the paper-photo proportions, it represents approximately 35.98 mm.

The appropriate result label is "Measured head height is within range." It describes exactly what the comparison established.

Which measurement edge cases need special handling?

Handle these two cases before presenting a result.

A resized preview. The approximately 756–850-pixel range belongs to the 1063-pixel-high export.

A rounded boundary. "71–80%" and "756–850 pixels" are useful display labels, but they are approximations.

Both cases can produce a misleading answer even when your annotation endpoints are correct.

What must you inspect beyond the pixel checks?

Review appearance separately from geometry.

The background must be plain, light and even, ideally neutral grey, with no shadows. Your face must be centred, sharp and evenly lit.

Check your expression: neutral, mouth closed, looking straight at the camera.

If you wear glasses, there must be no glare or tinted lenses, and the frames must not cover your eyes. Head coverings are allowed only for religious reasons.

Review those requirements separately. Neither detection nor an in-range measurement guarantees acceptance.

Where can you try the browser check?

You can use my free Schengen photo tool or the French checker.

When implementing the annotation workflow above, make the endpoints visible alongside the numerical result. That lets you inspect the measurement the code actually tested.

Disclosure: I built pixtidy.

Why a DS-160 photo can be too small, and how I test it in the browser

Jason T. — Sat, 03 Oct 2026 15:37:57 +0000

At 600×600, the DS-160 compression limit implies a minimum of 54,000 JPEG bytes. Your file must also stay at or below 240 KB. To test both limits in your browser, measure decoded dimensions and encoded bytes, then review composition separately.

You can test your own photo's size, bytes and head height with the free DS-160 photo checker in your browser (disclosure: I built it).

I built pixtidy, which uses MediaPipe face detection in your browser without uploading your photo. The distinction I care about is what each result checks: file measurements cover the digital limits, while landmark-based measurements cover composition. Some rules need your own review.

What are the DS-160 photo requirements in numbers?

Check the file against each limit independently.

The State Department's digital image requirements specify:

Property	Requirement
Shape	Square
Dimensions	600×600 through 1200×1200 pixels
Format	Color JPEG
File size	240 KB or less
Compression ratio	No higher than 20:1

The photo composition template adds two measurements:

Measurement	Requirement
Chin to top of hair	50–69% of image height
Eyes, measured up from the bottom	56–69% of image height

You need both sets of checks.

How do you check file size and compression together?

Read dimensions from the decoded image and bytes from the JPEG you intend to submit.

This JavaScript illustrates the measurements. It assumes blob contains the JPEG being tested. For the ceiling check, I use a conservative decimal interpretation of 240 KB: 240,000 bytes.

const image = await createImageBitmap(blob);
const { width, height } = image;

const encodedBytes = blob.size;
const rawRgbBytes = width * height * 3;
const compressionRatio = rawRgbBytes / encodedBytes;

const checks = {
  square: width === height,
  dimensions:
    width >= 600 && width <= 1200 &&
    height >= 600 && height <= 1200,
  fileSize: encodedBytes <= 240 * 1000,
  compression: compressionRatio <= 20
};

console.table({
  width,
  height,
  encodedBytes,
  rawRgbBytes,
  compressionRatio
});
console.table(checks);

image.close();

The file-size ceiling and compression limit now appear alongside each other.

At 600×600, the calculation is:

Raw RGB bytes = 600 × 600 × 3 = 1,080,000
Minimum encoded bytes = 1,080,000 ÷ 20 = 54,000

At exactly 54,000 bytes, the ratio is 20:1. Any smaller encoded file exceeds that ratio under this calculation.

If you export another JPEG, rerun the measurements on that output. Use its file size and dimensions to calculate its compression ratio.

How do you turn face coordinates into composition percentages?

Make the coordinate conversion explicit.

There are two separate jobs here: identifying anatomical positions and converting those positions into percentages.

For the head-height calculation, the endpoints are the chin and the top of the hair. For the eye-line calculation, you need the eyes' vertical position. Each measurement is expressed as a fraction of image height.

Here is the measurement layer. Its inputs are normalized vertical coordinates measured down from the top, rather than an assumed set of MediaPipe landmark indices:

function measureComposition({
  imageHeight,
  chinYNormalized,
  eyeYNormalized,
  topOfHairYNormalized
}) {
  const chinY = chinYNormalized * imageHeight;
  const eyeY = eyeYNormalized * imageHeight;
  const topOfHairY =
    topOfHairYNormalized * imageHeight;

  const headFraction =
    (chinY - topOfHairY) / imageHeight;
  const eyesFromBottom =
    (imageHeight - eyeY) / imageHeight;

  return {
    chinY,
    eyeY,
    topOfHairY,
    headPercent: headFraction * 100,
    eyesFromBottomPercent: eyesFromBottom * 100,
    headInRange:
      headFraction >= 0.50 && headFraction <= 0.69,
    eyesInRange:
      eyesFromBottom >= 0.56 && eyesFromBottom <= 0.69
  };
}

What do the composition limits look like at 600×600?

Convert the official percentages into pixel boundaries you can inspect.

For a 600-pixel-high image, the permitted chin-to-hair distance is:

Minimum head height = 600 × 0.50 = 300 pixels
Maximum head height = 600 × 0.69 = 414 pixels

The eye-line rule starts at the bottom. Converted to top-origin coordinates, its boundaries are:

At 56% from bottom: eyeY = 600 × (1 - 0.56) = 264
At 69% from bottom: eyeY = 600 × (1 - 0.69) = 186

Substituting the boundary coordinate 264 gives (600 - 264) / 600 * 100 = 56%.

For the head measurement, keep the chin coordinate explicit. A top-of-hair coordinate of chinY - 300 gives:

Head percentage
= (chinY - (chinY - 300)) / 600 × 100
= 50%

That is a boundary calculation. It illustrates the percentage conversion rather than how the coordinates are obtained.

Which mistakes still need manual review?

Check these cases before relying on a numerical result.

Glasses pass unnoticed. Glasses are not allowed except for a medical reason with a signed statement. Pixtidy does not check glasses.

Filters and AI edits. Photos must not be edited with filters or AI.

Where can you test your photo?

You can use the free pixtidy checker in your browser, without uploading your photo. There is also a full DS-160 photo rejection guide.

Use the measurements to find specific issues. Review the rules outside the checker's scope yourself.

Disclosure: I built pixtidy.

US passport photo costs in 2026: Walgreens, USPS, PhotoAiD and a DIY option

Jason T. — Thu, 01 Oct 2026 16:18:52 +0000

I built pixtidy, one of the options below. I'm its solo developer. This comparison includes my product, with its limits alongside the paid alternatives. Buy the format your application needs, rather than choosing by price alone.

What the listed price buys

A passport photo price can describe different purchases. A pair of finished prints is different from a digital file. Having someone take the picture is different from taking it yourself and paying for processing afterward.

Here are the listed prices and what each includes. Prices change and vary by location.

Option	Price	What you receive	What you do yourself	Source and price check date
Walgreens, in store	$16.99	Two printed photos plus a digital copy by email; someone takes the photo with proper lighting and a backdrop	Visit the store for the photo	Walgreens, October 1, 2026
USPS	$15	Passport photos at participating Post Offices, with someone taking the photo and providing prints	Visit a participating Post Office	USPS notice, published June 2, 2025, October 1, 2026
PhotoAiD	$13.95, Premium plan	AI cropping and background adjustment, followed by a person's review	Take the initial photo	PhotoAiD US passport photo page, October 1, 2026
pixtidy	$9.99 digital; $12.99 with a 4x6 print sheet	A digital photo, or the digital photo with a sheet you print yourself; checking is free before payment	Take the photo and, if needed, print the sheet	pixtidy, October 1, 2026

CVS's site returned 403 when checked on October 1, 2026, so I am not quoting a price.

The distinction I would watch most closely is "print sheet" versus "printed photos." Those labels describe different deliverables. A downloadable sheet leaves a printing step between purchase and a paper application. Comparing its listed price with an in-store price without that distinction makes the purchase look more equivalent than it is.

The PhotoAiD price above is specifically the Premium plan listed on its US passport photo page. I would compare that named plan with the service I actually wanted, rather than treating an online provider's price as interchangeable with a store's package.

Which option fits your application

DS-11 or DS-82 by mail

Paper applications need a printed 2x2-inch photo. A digital file alone does not meet that format requirement. Start with the required output before deciding how to get it. See the State Department photo guidance.

For someone who wants the photography and printing handled for them, I would choose Walgreens or a participating Post Office. Their advantage over my self-service option is practical: someone else handles the light and backdrop, and you receive prints. That is a reason to pay for the service, even if a digital option has a lower listed price.

If you prefer doing the photography yourself, distinguish between buying a file and finishing the application-ready print. The table's print-sheet option belongs in that workflow, rather than in the same category as walking away with finished photos.

Online passport renewal

Online passport renewal needs a digital file. Printed photos are therefore not the output to optimize for. See the State Department photo guidance.

For this situation, my recommendation depends on who you want doing the work. A self-service digital purchase fits someone comfortable taking the picture. Walgreens remains a relevant alternative when you want someone to photograph you, because its package includes an emailed digital copy. PhotoAiD makes more sense when a person's review matters to you.

I would not dismiss the store option merely because the application is online. The purchase includes help creating the image, not only the medium in which you receive it.

DS-160

The DS-160 also needs a digital file. That makes the digital deliverable the starting point here, too.

Use the same division of labor when evaluating options. Decide whether you want to take the picture yourself or have someone photograph you, then consider whether you want human review. Do not treat the price of a printed-photo package as the whole answer to a digital-file task.

Where self-service falls short

pixtidy runs in the browser, and the photo is never uploaded. You take the picture yourself, without a human reviewer. It does not retouch faces or replace backgrounds. If the wall is not white enough, it tells you to retake the photo. The refund condition is specific: a full refund applies if an official rejects a photo the checker passed.

If any of those limits is a dealbreaker for you, one of the other options is the better pick.

There is also an application rule separate from any product's feature list: the State Department says photos must not be altered with software or filters. That guidance is worth reading before choosing an editing workflow. It does not, by itself, establish that a named service's output will be accepted or rejected.

If you already have a photo, you can check it against the State Department rules for free, with no sign-up, at pixtidy.com/passport-photo-checker. The comparison above is also kept as a page with sources and the date each price was checked: pixtidy.com/passport-photo-cost.

Disclosure: I built pixtidy, one of the options above. I'm not affiliated with Walgreens, USPS or PhotoAiD.

App Store and Google Play screenshot sizes in 2026 (and the rules that get uploads rejected)

Jason T. — Thu, 01 Oct 2026 06:28:38 +0000

Every release I end up re-checking the same thing: which screenshot sizes does App Store Connect want this year, and what will Google Play reject? Here are the official numbers in one place, plus the rules that trip people up. Sources are linked at the bottom.

To skip manual resizing, my browser-based App Store & Google Play screenshot generator adds captions and exports every size without uploading screenshots (disclosure: I built it).

App Store: what you actually have to provide

Apple accepts screenshots only at exact pixel sizes. A few pixels off and the upload fails.

Display	Accepted portrait sizes (px)	Required?
iPhone 6.9"	1320×2868, 1290×2796, 1260×2736	Yes, for iPhone apps (or provide 6.5")
iPhone 6.5"	1284×2778, 1242×2688	Only if you don't provide 6.9"
iPhone 6.3"	1206×2622, 1179×2556	No (scaled from 6.5")
iPhone 6.1"	1170×2532, 1125×2436, 1080×2340	No (scaled from 6.5")
iPad 13"	2064×2752, 2048×2732	Yes, if your app runs on iPad
iPad 11"	1668×2420, 1668×2388, 1640×2360, 1488×2266	No (scaled from 13")

Landscape versions of each size are accepted too. In practice, if you ship one iPhone set at 6.9" and, for iPad apps, one set at 13", the smaller displays are scaled from those.

Other rules:

1 to 10 screenshots per display size
JPG or PNG
No alpha channel or transparency. This one bites people who export PNGs from design tools or from <canvas>: a canvas PNG always has an alpha channel, even when every pixel is opaque. Exporting JPEG avoids it entirely.

Google Play: rules instead of a size list

Play doesn't publish a fixed list. Phone screenshots must be:

JPEG or 24-bit PNG, no alpha
Each side between 320 px and 3,840 px
The long side no more than twice the short side. A tall modern phone capture (for example 1080×2400, which is 2.22:1) breaks this rule, so you can't upload raw screenshots from many current Android phones without adding padding or a background.

To be eligible for Play's large-format recommendation slots, apps need at least four screenshots at 1080 px or more, in 9:16 portrait (1080×1920 or larger) or 16:9 landscape.

The content guidelines also matter if you add marketing captions:

Taglines should take up no more than 20% of the image
Avoid performance, ranking, price or promo claims: "Best", "#1", "Top", "New", "Free", "Discount", "Sale", "Million Downloads"
No calls to action like "Download now" or "Install now"

The feature graphic is separate: 1024×500, JPEG or 24-bit PNG, no alpha.

A layout that satisfies both stores

What has worked for me is a caption band at the top and the real screenshot below it, scaled to fit, never stretched:

// caption band: 18% on Play (under the 20% limit), ~22% on the App Store
const capH = Math.round(target.height * (target.store === "play" ? 0.18 : 0.22));
const pad = Math.round(target.width * 0.08);
const boxW = target.width - pad * 2;
const boxH = target.height - capH - pad;
const scale = Math.min(boxW / shot.width, boxH / shot.height); // fit, keep aspect ratio
const w = Math.round(shot.width * scale), h = Math.round(shot.height * scale);
const x = Math.round((target.width - w) / 2);
const y = capH + Math.round((boxH - h) / 2);

Render it on a canvas at the exact target size, then canvas.toBlob(cb, "image/jpeg", 0.92) so there is no alpha channel to worry about.

I got tired of doing this by hand, so I built a small browser tool that does exactly this: you add captions to your screenshots and it exports every size above, checks them against these rules (including flagging the Play-banned words in your captions), and nothing gets uploaded: App Store & Google Play screenshot generator. Disclosure: I made it. Previews are free; downloading the full set is a one-time payment.

Sources

Both checked October 2026. If you've hit a rejection reason that isn't covered here, I'd like to hear it in the comments.

Hitting a file-size window with canvas.toBlob: fitting passport photos into 54–240 KB

Jason T. — Wed, 30 Sep 2026 19:21:22 +0000

Government photo upload forms are strict about file size, and they are strict in both directions. The US DS-160 visa form wants a JPEG of at most 240 KB with a compression ratio no higher than 20:1. China's online visa form wants 40–120 KB. Upload a 30 KB file and it gets rejected for being "too compressed"; upload 300 KB and it is too big.

You can check your own photo against these rules for free in your browser on this page; the photo is never uploaded (disclosure: I built it).

Most people fix this by re-saving in an image editor until it works. When you build a tool that does it automatically, it turns into a neat little search problem. Here is how I handle it in the browser, with no server involved.

Step 1: turn the rules into a byte window

A "compression ratio" limit is really a minimum file size in disguise. The ratio compares the raw bitmap size to the compressed file size:

raw bytes = width × height × 3        (24-bit RGB)
ratio     = raw bytes / file bytes

For a 600×600 DS-160 photo the raw bitmap is 1,080,000 bytes, so a ratio of at most 20:1 means the file must be at least 54,000 bytes. Put that next to the stated maximum and the rules become a window:

export function byteBounds(spec: PhotoSpec) {
  const d = spec.digital;
  if (!d) return undefined;
  const raw = spec.output.widthPx * spec.output.heightPx * 3;
  const fromRatio = d.maxCompressionRatio ? Math.ceil(raw / d.maxCompressionRatio) : 0;
  return { minBytes: Math.max(d.minBytes ?? 0, fromRatio), maxBytes: d.maxBytes };
}

One more gotcha: official pages say "KB" without saying whether they mean 1000 or 1024 bytes. For a minimum I use ×1024, and for a maximum ×1000. The file then passes whichever way the validator reads it.

Step 2: binary-search the JPEG quality

canvas.toBlob(cb, "image/jpeg", quality) gives you exactly one knob. File size grows with quality, roughly monotonically, so binary search works well. I inject the encoder so the logic can be unit-tested without a canvas:

const Q_MIN = 0.3;
const Q_MAX = 1;

export async function fitJpeg<T extends { size: number }>(
  encode: (quality: number) => Promise<T>,
  { minBytes, maxBytes }: { minBytes: number; maxBytes: number },
  iterations = 8,
) {
  const best = await encode(Q_MAX);
  if (best.size <= maxBytes) {
    return best.size >= minBytes ? { ok: true, result: best } : { ok: false, reason: "too-small", result: best };
  }
  const worst = await encode(Q_MIN);
  if (worst.size > maxBytes) return { ok: false, reason: "too-large", result: worst };

  let lo = Q_MIN, hi = Q_MAX, fit = worst;
  for (let i = 0; i < iterations; i++) {
    const q = (lo + hi) / 2;
    const r = await encode(q);
    if (r.size <= maxBytes) { fit = r; lo = q; } else { hi = q; }
  }
  return fit.size >= minBytes ? { ok: true, result: fit } : { ok: false, reason: "too-small", result: fit };
}

A few design choices:

Aim for the largest file that fits, not the first one. Officers look at these photos. The more quality you keep under the cap, the fewer "blurry photo" rejections you get.
Check the extremes first. If quality 1.0 already fits, stop there. If quality 0.3 is still too large, the pixel dimensions are wrong and no quality setting will fix it. Report that instead of looping.
Eight iterations is plenty. That narrows quality to about 0.003, well below the point where file size visibly changes.
"Too small" is a real failure. A flat, mostly white photo can compress below the minimum even at quality 1.0. It's better to report that clearly than to pad the file with junk bytes.

In the browser the encoder is just a promise wrapper:

const toBlob = (c: HTMLCanvasElement, q: number) =>
  new Promise<Blob>((res, rej) => c.toBlob((b) => (b ? res(b) : rej(new Error("encode failed"))), "image/jpeg", q));

const fit = await fitJpeg((q) => toBlob(photo, q), byteBounds(spec)!);

Step 3: test it without a browser

Because the encoder is injected, the tests use a fake whose size is a function of quality:

const fake = (bytesAt: (q: number) => number) => async (q: number) => ({ size: bytesAt(q), q });

it("returns the largest file under the cap", async () => {
  const r = await fitJpeg(fake((q) => Math.round(400_000 * q)), { minBytes: 54_000, maxBytes: 240_000 });
  expect(r.ok).toBe(true);
  expect(r.result.size).toBeLessThanOrEqual(240_000);
  expect(r.result.size).toBeGreaterThan(235_000);
});

Where the numbers come from

The limits above come from the official pages (travel.state.gov for DS-160, the Chinese visa application service for China). I keep them, with sources, in an open dataset: passport-photo-requirements on GitHub (CC BY 4.0, JSON). There is also a side-by-side table of requirements by country.

For the US visa (DS-160) photo specifically, where the 240 KB cap applies, there is a free browser-based checker at pixtidy.com/us-visa-photo-checker.

This code runs inside pixtidy, a passport and visa photo maker I built. Face detection, cropping and this size fitting all happen in the browser, so the photo never leaves the device. If you've run into other odd government upload rules, I'd like to hear about them in the comments.

Checking passport photos against government specs in the browser with MediaPipe

Jason T. — Wed, 30 Sep 2026 17:11:26 +0000

Government photo rules read like a spec sheet. The DS-160 (US visa) wants a square JPEG between 600×600 and 1200×1200 px, at most 240 KB, with the head (chin to top of hair) taking 50–69% of the image height and the eyes 56–69% up from the bottom. The Chinese visa wants 354×472 px, 40–120 KB, and the crown 10–70 px below the top edge. India's OCI photo must have a light background that is not white.

The checks below run free in the browser in pixtidy; your photo is never uploaded (disclosure: I built it).

A spec sheet can be turned into code, so I built a checker that runs entirely in the browser: the photo never leaves the device, and there's no server-side inference to pay for. This post walks through the pipeline and the parts that were harder than expected.

The stack

@mediapipe/tasks-vision with two models, served from our own origin:
- FaceLandmarker (478 landmarks + blendshapes + a facial transformation matrix)
- ImageSegmenter with the selfie segmentation model
Plain <canvas> for rotation, cropping, pixel statistics and JPEG encoding
No uploads and no third-party scripts

const fileset = await FilesetResolver.forVisionTasks(WASM_PATH); // self-hosted wasm
const face = await FaceLandmarker.createFromOptions(fileset, {
  baseOptions: { modelAssetPath: "/models/face_landmarker.task", delegate },
  runningMode: "IMAGE",
  numFaces: 2, // we need to know if there's more than one
  outputFaceBlendshapes: true,
  outputFacialTransformationMatrixes: true,
});

numFaces: 2 is deliberate. If you ask for one face you can't tell a clean portrait apart from a photo with someone standing behind you, and "no other people in the photo" is a rule almost everywhere.

Step 1: level the eyes before measuring anything

Phone photos are rarely level. Every measurement downstream (head height, eye line, crop box) assumes an upright head, so the first step is to rotate around the midpoint between the irises:

const roll = rollFromEyes(irisLeft, irisRight); // atan2 of the eye line, in degrees
if (Math.abs(roll) > 1) {
  source = rotate(source, roll, cx, cy);
  res = face.detect(source); // re-run landmarks on the levelled image
}

Is rotating allowed? For in-plane tilt, yes: the US State Department's own photo tool rotates. What you must never do is warp or retouch the face. After rotating, the canvas corners are blank, so the crop search is constrained to rectangles that stay inside real pixels.

Step 2: finding the top of the head (landmarks stop at the forehead)

This was the least obvious part. Every official spec measures head height from the chin to the crown (top of the hair), but the face mesh stops at the hairline. Using the forehead landmark underestimates head height by roughly 20%, and that is enough to fail a 50–69% window.

The fix is the segmentation mask. Scan down from the top of the image inside the face's column band and take the first row where several columns are "person":

export function findCrownY(mask, w, h, x0, x1, maxY, minColumns = 2) {
  for (let y = 0; y <= maxY; y++) {
    let hits = 0;
    for (let x = x0; x <= x1; x++) if (mask[y * w + x] === PERSON) hits++;
    if (hits >= minColumns) return y;
  }
}

Two details matter:

Only scan the middle 60% of the face width, so shoulders and raised hands at the edges don't count as "head".
Require a minimum run of columns (about 10% of the face width) so a few stray mask pixels don't pull the crown up.

If the mask finds nothing (a bald head against a white wall can blend in), fall back to forehead − 0.2 × (chin − forehead).

Model size matters for a page people open on their phone. I started with the 16 MB multiclass segmenter (hair, face skin, body, background) and replaced it with the ~250 KB person/background selfie model, which treats hair as "person". On my test portraits the crown positions agreed within about 1.5% of head height, which is well inside every spec's tolerance.

Step 3: solve for the crop, don't guess it

With the crown, chin, eye line and face center known, the crop is a small constraint problem. Each spec gives some of:

head height as a fraction of the image height (e.g. [0.50, 0.69])
eye line as a fraction from the bottom (e.g. [0.56, 0.69])
crown margin from the top edge (China: 10–70 px of 472)
output size and aspect ratio

Pick the scale that puts the head at the middle of its allowed range, place the eyes in the middle of theirs, center horizontally, then check that the rectangle still sits inside the image. If the person is too close to the camera, no rectangle fits, and we tell them to step back instead of silently producing a bad crop.

Some specs publish no head-size number at all (the UK digital visa photo, New Zealand passport). For those we use a clearly labelled "recommended framing" rather than inventing a rule.

Step 4: the checks

Everything after the crop is measured on the output-sized image, because that is what the government system will see.

Rule	Signal
Eyes open	blendshapes `eyeBlinkLeft/Right` < 0.5
Mouth closed	`jawOpen` < 0.25, plus the lip gap relative to face height
Facing the camera	yaw from the facial transformation matrix, warn at 5°, fail at 10°
Background	mean and standard deviation of luma over non-person pixels
Lighting	mean luma of the face box within 70–210
Sharpness	variance of the Laplacian on the face box, resized to 256 px wide

One surprise: pitch from MediaPipe's transformation matrix reads 10–17° on perfectly frontal official sample portraits. Failing on pitch would reject good photos, so pitch only ever warns.

Background checks depend on the spec: "white" (US) needs a mean above 200 with low variance, while OCI needs a light background that is not white. The same pixels can be a pass for one document and a fail for another, which is why every check reads its thresholds from the spec object instead of hard-coding them.

Step 5: hitting the file-size window

Many portals have a minimum and maximum file size (China: 40–120 KB, Australia: 70 KB–3.5 MB) and some cap the compression ratio. canvas.toBlob(cb, "image/jpeg", q) is monotonic enough in q that a binary search works:

export async function fitJpeg(encode, { minBytes, maxBytes }, iterations = 8) {
  const best = await encode(1);
  if (best.size <= maxBytes) return best.size >= minBytes ? ok(best) : tooSmall(best);
  const worst = await encode(0.3);
  if (worst.size > maxBytes) return tooLarge(worst);
  let lo = 0.3, hi = 1, fit = worst;
  for (let i = 0; i < iterations; i++) {
    const q = (lo + hi) / 2, r = await encode(q);
    if (r.size <= maxBytes) { fit = r; lo = q; } else { hi = q; }
  }
  return fit.size >= minBytes ? ok(fit) : tooSmall(fit);
}

encode is injected so the search is unit-tested without a canvas. Eight iterations are enough to land within a few KB of the limit, and we take the largest file that fits, because a bigger file means less compression and better quality.

What I'd tell anyone building something similar

Store the source for every number. Each spec in the code links to, and has an archived copy of, the government page it came from. Requirements disagree across pages (the Vietnam e-visa portal states both a 2 MB and a 10 MB limit) and you need to be able to say why you chose one.
Test on official sample photos. Governments publish "acceptable" examples. If your checker fails them, your thresholds are wrong, and that is how the pitch issue showed up.
Never retouch. It's tempting to "fix" backgrounds or smooth skin, but US, UK, Australian and New Zealand guidance explicitly rejects edited photos. Crop, level and resize only.

The spec data (21 documents, with sources) is open on GitHub: tensam/passport-photo-requirements, and browsable as a table at pixtidy.com/photo-requirements. The checker itself is at pixtidy.com. The check is free; I'm the developer, so feedback on edge cases (glasses glare, very dark skin against a white wall, babies) is very welcome.