"Photo Dimensions Invalid" on Passport Seva: The Real Fix

"Photo dimensions invalid" on a passport portal almost always means your JPG is not exactly 630×810 pixels — not a random server error and not a signature problem.

Key takeaways

• The photo dimensions invalid error passport portal message refers to pixel width and height read from your file header — not print millimeters and not file size in KB.
• Close sizes like 600×800, 640×840, or 631×809 fail the same way as obviously wrong landscapes; validators compare integers, not how the photo looks on a phone screen.
• Fixing the error requires re-export from the original photo with a locked 7:9 crop, then a single resize to 630×810 — not re-uploading the same file hoping the server changes its mind.
• DPI metadata alone does not satisfy the validator if pixel integers are wrong; set 300 DPI on export, but verify width and height on the saved file every time.
• Some browsers and mobile upload paths cache a failed file name — rename the corrected export before retry, and use a fresh session if the portal still shows the old error.
• OCI and visa portals use different dimension pairs; Passport Seva expects the Indian passport pixel spec unless the form states otherwise — verify on the official notification before you upload.

Passport Seva and related government upload flows show minimal error text. "Photo dimensions invalid" is one of the clearer messages — yet forums fill with guesses about browser version, VPN, or server downtime. In most cases the server correctly rejected a file whose dimensions are not the published pair. This guide maps symptoms to causes, walks through measurement on Windows, macOS, and phone, and separates true dimension failures from KB, format, and session errors covered in passport photo rejected guides.

If you have already retried the same file three times, stop. Open file properties on the actual JPG on disk, read width and height, and route yourself to Cause 1 or Cause 2 below. That single measurement saves more time than any browser tweak.

Most applicants who hit a photo dimensions invalid error passport portal message are one re-export away from a clean upload — they just have not measured the file they are actually attaching. The sections below walk through that measurement, the two root causes, and the export sequence that clears the error without a studio visit.

Start here: confirm it is really a dimension error

Before editing, read your file's actual pixel width and height on disk. Compare to the portal's stated requirement — typically 630×810 for standard Indian passport upload at 35×45 mm and 300 DPI.

The photo dimensions invalid error passport portal users see should correlate with row one after measurement — if your file is already 630×810, do not chase pixel math; move to Cause 2.

Write down three numbers before you touch an editor: width in pixels, height in pixels, and file size in KB. Keep the official notification open beside your file manager so you compare against the current cycle spec, not a coaching handout from a prior year. A photo that passed a friend's upload last year may fail today if the portal tightened validation or if you are on a different form type entirely.

Quick measurement checklist

1. Locate the exact file you plan to upload — not a thumbnail, not a preview inside an editing app.
2. Open Properties on Windows, Get Info on macOS, or Details in your phone gallery.
3. Record width × height and KB size in a note.
4. Match width and height against 630×810 first; only then check KB and format.

If any step is uncertain, transfer the file to a desktop and measure there. Mobile gallery apps sometimes show resolution labels that reflect screen scaling rather than the saved JPG header.

Cause 1: Wrong pixel width or height

Cause 1 is any export whose integer pixel dimensions differ from the required pair. The portal does not accept "close enough," "looks right," or "the studio said passport size." It reads two integers from the JPEG header and compares them to the expected values.

Common sources of Cause 1:

Generic resize fields — You typed 600×800, accepted an app default, or used a slider that rounded output. Many free editors default to round numbers that feel "about right" but miss the spec by ten or twenty pixels per side.

Aspect ratio lock missing — Width set to 630 while height auto-calculated to 805, 808, or 820 because the crop was not locked to 7:9 before resize. Each axis must land on the exact target after a single resize pass.

Square or US visa crop — 600×600, 512×512, or 2×2 inch presets from a generic "ID photo" button. Indian passport upload expects portrait 630×810, not square profile dimensions. If you are preparing for a visa form instead, see Indian visa photo size for visa-specific pairs before you upload to a visa portal.

Screenshot upload — A screen capture records device pixels, not document spec. Even when the screenshot shows your face correctly framed, the saved file dimensions reflect your phone display, not 630×810.

Messaging app recompression — WhatsApp, Telegram, and similar apps often change dimensions in transit even when you choose "document" send. Always measure on the receiving device before upload.

Studio USB stick with wrong digital master — The print may measure 35×45 mm with a ruler while the JPG reads 640×840 because the shop software used a different preset. Applicants upload the digital file, get rejected, and blame the studio print because they never checked properties on the JPG.

Fix for Cause 1: From your highest-quality original: crop to 35:45 (7:9) with aspect locked, resize once to 630×810, set background to pure white, compress to the KB range the portal accepts, verify properties on the exported file, then upload a renamed copy such as passport-630x810-v2.jpg.

Dimension near-miss table

Do not rely on "close enough." Re-export exact integers. Automated checks treat off-by-one the same as off-by-hundreds.

How to re-export without repeating Cause 1

Use a passport-calibrated export preset or set Image Size in Photoshop or GIMP with aspect locked after crop. Never scale the full uncropped phone image directly to 630×810 without cropping first — the dimensions may read correct while face proportion violates biometric guidelines, which can fail later at manual review even after the dimension gate passes.

Crop-first workflow:

1. Open the original photo at full resolution.
2. Crop to 7:9 with the face centred and roughly 70% of frame height from chin to crown — verify against the current government photo notification.
3. Resize the cropped canvas once to exactly 630 pixels wide and 810 pixels tall.
4. Flatten to white background with no shadow or colour fringe at hair and shoulders.
5. Export JPG, then open Properties before you celebrate.

Resize-before-crop failure mode: Resizing a large uncropped image to 630×810 squeezes the entire scene into passport aspect, making the face tiny. Some applicants then crop in a second step, which changes pixel dimensions again and often yields 628×810 or 630×808 from double rounding. Crop first, resize once.

Editor-specific traps

Save for Web vs Export As — In Adobe tools, different export dialogs can write different pixel dimensions from the same on-screen canvas. Always re-open Properties after export, not after preview.

Canvas size vs visible crop — An image can display as 630×810 in the editor while the saved canvas includes extra transparent or coloured pixels outside the crop box. Flatten and crop explicitly before export.

"Passport size" presets in generic apps — Many mobile apps inherit square-first architecture from profile-photo features. The label says passport; the output is 1:1 or US 2×2. Measure every export regardless of preset name.

Batch tools — Family photo sessions exported in bulk sometimes apply one wrong setting to every file. Fix the master workflow once, then re-export all applicants from source originals.

Cause 2: Not dimensions — KB, format, or session

Cause 2 covers uploads where the message says dimensions invalid but measurement shows 630×810 — or where fixing pixels did not help after two careful retries.

File size in KB — Below the portal minimum, some flows report corrupt or invalid image rather than "file too small." Above the maximum, upload may fail before or after the dimension check depending on portal order. Compress or re-export quality without changing pixel dimensions once width and height are confirmed.

PNG labelled or renamed as JPG — Some validators misreport format failures as dimension or generic invalid errors. Export baseline JPG from a proper encoder, not a PNG renamed to .jpg.

HEIC from iPhone — Default camera format is often not accepted. Convert to JPG before the upload path; confirm pixels after conversion because some converters also resize.

Browser cache and stale attachment — The file picker reattaches an old failed upload even after you saved a corrected export elsewhere. Rename the file, clear the input, or switch to incognito.

Session timeout — Long form sessions expire. Re-login and upload a fresh export rather than retrying on a dead session.

Ad blockers or extensions — Occasionally interfere with multipart upload on government sites. Try a clean browser profile without extensions.

Wrong form, right passport file — OCI and visa flows may expect different pixel pairs. A perfect 630×810 passport export fails on an OCI field expecting another size. Verify OCI photo size when the form is OCI, not standard passport renewal.

When pixels are correct, follow passport photo rejected KB and format branches instead of endlessly tweaking width and height.

Distinguishing error messages

The photo dimensions invalid error passport portal text is narrower than "invalid photo" — still verify KB if 630×810 is confirmed on disk.

When Cause 2 masquerades as Cause 1

Applicants sometimes compress aggressively to fix KB and accidentally resize pixels in the same dialog. If your editor's "save for web" bundle changes both quality and dimensions, you can leave a session thinking pixels are still 630×810 when the new file is 620×798. Re-measure after every save, not only after the first export.

iCloud or Google Photos sync — Cloud services may serve an optimized copy with different dimensions than the original you edited locally. Download the exact file to disk and measure before upload.

Duplicate filenames in Downloads — passport.jpg, passport (1).jpg, and passport-final.jpg cause repeat uploads of an old incorrect export. Rename after each fix and delete confusing duplicates weekly.

Worked example: near-miss fixed in one export

An applicant uploads a file labelled passport-ready from a generic app. Properties show 640×840 px and 38 KB. The portal returns photo dimensions invalid. They crop the original phone photo to 7:9, resize once to 630×810, re-compress to 32 KB, rename to passport-v2.jpg, and upload from a fresh Chrome window. Upload succeeds. No retake, no studio — only correct integers. That pattern matches most Cause 1 reports when you trace them back to the saved file rather than the error text alone.

Why portals enforce exact pixels

Automated pipelines store applicant photos in fixed aspect slots for printing, database consistency, and downstream biometric processing. Variable sizes would require server-side resampling — government flows push that responsibility to the applicant before upload.

Exact 630×810 matches 35×45 mm at 300 DPI without server guesswork. When every file arrives at the same pixel pair, print templates, appointment counter checks, and archival systems align. When sizes vary, a single downstream step — batch print, quality review, or data migration — must guess how to normalize images. Portals avoid that guesswork by rejecting anything that does not match the published integers.

This is separate from whether your photo looks good. A validator never sees your face until width and height pass. That ordering explains why KB tweaks do not help until pixels match: the dimension gate runs early in many upload flows.

Millimeters matter at the print shop. Pixels matter online. Applicants who conflate the two often upload a scan of a correct print at 1200×1600 thinking higher resolution helps — scan pixels are not spec pixels. Export a digital master at 630×810; scan only if the form explicitly asks for a scan of a physical print.

How to measure your file before you edit anything

Measurement takes under a minute and prevents hours of wrong fixes.

Windows: Right-click the JPG → Properties → Details tab → Dimensions field shows width × height. Also note Size in KB on the General tab.

macOS: Select the file → File → Get Info → More Info section lists dimensions. Quick Look preview does not replace Get Info for official measurement.

Android: Open the image in Gallery or Files → Details or Info → Resolution.

iPhone: Photos app → swipe up on the image → adjust EXIF details if shown; when in doubt, AirDrop or cable-transfer to a desktop and confirm there.

Measure the exported JPG you will upload, not an editor preview screenshot. Measure after every export pass, not only the first.

What to record in your notes

If width and height pass but upload still fails, move to KB and format in Cause 2. Do not resize again "just in case" — you risk drifting back into Cause 1.

Step-by-step re-export that clears the error

Follow this sequence in order. Skipping steps or reversing crop and resize order is why corrected files still fail.

1. Start from the best original — Highest resolution capture with even lighting and plain background. Do not chain-edit an already compressed export.
2. Crop to 7:9 with aspect locked — Face centred; chin-to-crown roughly 70% of frame height per current notification.
3. Resize once to 630×810 — Enter both integers explicitly; disable "scale proportionally" only after aspect is locked from the crop.
4. Background to pure white — Remove shadows and colour casts at hair, ears, and shoulders; flatten layers.
5. Export JPG — Note quality setting; aim for KB range the portal accepts, typically 20–50 KB for many flows — verify on the official site.
6. Measure on disk — Properties must show 630×810 and acceptable KB.
7. Rename file — Example: passport-630x810-v2.jpg to bust browser cache.
8. Upload from fresh session — Incognito or new login if prior attempts failed repeatedly.

Retry checklist after fix

If three corrected 630×810 uploads fail with the same message across two browsers and two devices, capture a screenshot of file properties and the portal error — scheduled maintenance or a temporary service issue is possible. Even then, re-export from source fixes the vast majority of reports; maintenance rarely changes the spec integers you must hit.

Visa and OCI: when the right passport file is the wrong file

Indian passport online upload expects 630×810 for the standard passport photo field. OCI registration, visa applications, and some ancillary forms may publish different pixel pairs or aspect ratios on their own notification pages.

Uploading a passport-perfect file to the wrong form produces dimension errors even when the passport spec is flawless. The validator compares your integers to the form you are on, not to the passport spec you memorized.

Before upload, read the notification beside the specific field you are filling:

• Standard Passport Seva renewal or fresh passport — typically 630×810 JPG unless the live form states otherwise.
• OCI — verify dimensions on OCI photo size; do not assume passport parity.
• Visa — verify Indian visa photo size; US 2×2 inch and other country presets differ from Indian passport pixels.

Keeping one master source photo and exporting form-specific copies into separate folders prevents cross-upload mistakes. Name folders after the form type, not after "final photo", and delete stale exports from Downloads once a week so you never attach the wrong version by habit.

Common mistakes that keep the error coming back

• Trusting the preview pane. Only the saved file on disk counts. Editor chrome and upload preview thumbnails lie often.
• Re-uploading the same file. The server will reject the same integers again. Re-export from original, rename, retry.
• Fixing KB before pixels. Compress only after width and height are exact; otherwise you may resize accidentally in the same step.
• Using WhatsApp to move the file. Even document mode can change pixels. Use cable, AirDrop, or cloud download with Properties check at destination.
• Assuming studio print equals digital master. Measure the JPG on the USB stick, not the cut paper.
• Applying US or EU presets. 2×2 inch and 35×45 mm are not interchangeable presets in most apps — read pixels, not preset labels.
• Upscaling a tiny source. Forcing 630×810 from a low-resolution crop invents pixels; dimension check may pass while quality fails later.
• Uploading oversized originals. 3000×4000 files expecting server-side resize — portals do not resize for you; crop and downscale locally.
• Ignoring orientation swap. 810×630 is not the same as 630×810 when the validator expects width first.
• Editing the same JPG repeatedly. Each save can change KB and occasionally dimensions if the editor re-encodes with different settings.

None of these require a new photo session if your original capture has enough resolution to crop correctly. They require discipline on export and measurement.

Mobile upload and file-transfer pitfalls

Mobile browsers sometimes attach a downscaled camera-roll copy even when the full-size file exists on the device. Export on desktop when possible, or use a tool that downloads an explicit 630×810 file, then transfer via cable or cloud without chat recompression.

Attachment pickers — "Choose photo" vs "choose file" may pull different assets. Prefer file picker pointed at Downloads where you saved the measured export.

Orientation tags — Rarely, EXIF orientation confuses viewers; width and height in Properties remain authoritative. If rotation looks wrong after upload preview, rotate in a desktop editor and re-save baseline 630×810 JPG, then re-measure.

Low-data mode — Some phones substitute optimized copies on slow networks. Upload from Wi-Fi after confirming file size and dimensions on disk.

When the dimension gate runs in upload, server flow typically parses the JPEG header before KB checks. A dimensions invalid response returns early when width or height mismatch — KB tweaks do not help until pixels match. That ordering is why measurement-first diagnostics beat random compression attempts.

Measure pixels first on every photo dimensions invalid error passport portal report — then KB, format, cache, and session in that order.

FAQ

What causes the photo dimensions invalid error passport portal shows? The JPG width or height in pixels does not match the required values — for standard Indian passport upload, that usually means anything other than exactly 630×810. The validator reads integers from the file header, not print millimeters.

I have 630×810 — why does it still say invalid? Likely Cause 2: file size outside the accepted KB range, PNG or HEIC format, browser cache reattaching an old file, or wrong form type expecting different pixels. Re-measure KB and format, rename the file, try a fresh browser session.

Does changing DPI alone fix the dimension invalid error? Not if pixel integers are wrong. Set 300 DPI on export for consistency with print spec, but fix width and height first. Two files can share DPI metadata and differ in pixels.

Can I fix this without taking a new photo? Yes — re-export from your original capture with correct 7:9 crop and single resize to 630×810. Most Cause 1 failures are export workflow problems, not bad lighting or expression.

Is 600×800 acceptable if it looks the same on screen? No for strict passport upload expecting 630×810. Close sizes fail automated checks the same as wildly wrong landscapes.

Why does the error appear after Photoshop save? Check Image Size values on the saved file, not the canvas. Save for Web and Export As can write different dimensions from the same view. Re-open Properties after every export.

Does OCI use the same dimensions as passport? Not always. OCI notifications publish their own requirements — verify on OCI photo size before uploading to an OCI form.

Can HEIC cause a dimension error message? HEIC often fails before parse or maps to generic invalid text. Convert to baseline JPG, then confirm 630×810 on the converted file.

Should I upscale a small photo to 630×810? Upscaling invents pixels and often fails quality review even when dimensions read correct. Start from a source with enough resolution to crop down, not up.

Does renaming the file help? Yes — browsers and portals sometimes reuse a cached failed attachment with the same filename. Rename each corrected export (v2, v3) before retry.

My phone gallery shows 630×810 but the portal fails — why? Gallery labels can reflect display scaling. Transfer to desktop, open Properties, and read the JPG header directly.

Is visa photo size the same as passport? Often different — US visa and other country presets use other inch or pixel targets. See Indian visa photo size for visa-specific pairs before upload.

Fix it now

Export at exactly 630×810 from your original photo — crop with aspect locked, white background, KB pass — and verify width and height on the downloaded file before uploading to Passport Seva. A passport-calibrated export prevents the wrong pixel pairs that trigger a photo dimensions invalid error passport portal message when generic resize boxes round output to "close enough" sizes.

The preset targets the pixel pair Indian passport portals expect so you do not hand-type dimensions into a generic resize box.

Measure first, guess never. If dimensions are exact and the error persists, switch to KB and format fixes in passport photo rejected — not endless pixel tweaks. Rename each new export and upload from a clean browser session to rule out cache.

Keep the original capture until upload succeeds. Repeated saves on the same JPG can change KB without changing dimensions, pushing you from a solved Cause 1 into Cause 2 on the next attempt. One careful export from source beats five incremental saves on an already compressed file.