PAN Card Photo Size: The Complete Guide for NSDL and UTIITSL
Spec pending verification against the official source — confirm on the official portal before you submit.
PAN card photo size depends on your operator: NSDL wants 213×213 px at 200 DPI; UTIITSL wants 640×640 px at 600 DPI — and mixing them up is the top rejection reason.
Key takeaways
- India routes PAN applications through two separate operators — NSDL (Protean eGov) and UTIITSL — and each publishes a different square photo spec. A file built for one is often rejected by the other.
- NSDL typically expects 213 × 213 pixels at 200 DPI. UTIITSL typically expects 640 × 640 pixels at 600 DPI. Both require a plain white background and a JPG export, but the pixel count and embedded DPI metadata are not interchangeable.
- File size in KB matters independently of pixel dimensions. A photo at the correct pixel count can still fail if it is too large to upload or too heavily compressed to pass quality checks.
- The operator is determined by the portal you are actually applying through, not by which search result you clicked first. Check the URL and branding before you prepare the photo.
- A passport photo, an aadhaar photo size upload, and a driving licence photo signature pair each follow different dimensions. Re-cropping from one document type to another is faster than fixing a rejection after submission.
- Verification takes under a minute: confirm pixel dimensions, file size, DPI metadata, background colour at 100% zoom, and that you matched the correct operator spec before you upload.
Why NSDL and UTIITSL use different PAN photo specs
PAN card issuance in India is handled by two authorised service providers: NSDL, now branded Protean eGov Technologies, and UTI Infrastructure Technology And Services Limited (UTIITSL). Both operators collect applications on behalf of the Income Tax Department, but they run separate portals, separate upload widgets, and separate technical validators for supporting documents including photographs.
That split is the root cause of most confusion around PAN card photo size. A search for "PAN photo requirements" returns generic advice — often copied from passport photo guides — that does not distinguish between operators, which is why a dedicated pan card photo size complete guide needs to treat NSDL and UTIITSL as separate workflows from the first paragraph. Applicants prepare a 35×45 mm rectangular passport-style image, or a square crop at the wrong pixel count, and only discover the mismatch when the upload field rejects the file or the application stalls at the photo step.
The two operators' specs differ on three independent variables: pixel dimensions, embedded DPI metadata, and in some cases colour mode expectations. NSDL's published target centres on a smaller square at 200 DPI. UTIITSL's published target is a larger square at 600 DPI. Submitting a 213×213 file to a UTIITSL form fails on dimensions. Submitting a 640×640 file to an NSDL form fails for the same reason. Submitting a file with the correct pixels but the wrong DPI tag can fail even when the image looks fine on screen, because some validators read the metadata field rather than calculating resolution from pixel count alone.
This pan card photo size complete guide treats the two operators as two separate workflows from the start, because that is how the portals actually behave. The transactional pan card photo size page on this site lists the core numbers; what follows here is the full operational detail — how to identify your operator, how to prepare the file, what the upload widgets check, and what to do when a compliant-looking photo still bounces back.
NSDL (Protean eGov) PAN photo requirements
If your application runs through the NSDL or Protean eGov portal, the photograph upload expects a square image at smaller dimensions than most other Indian identity documents use.
| Requirement | NSDL target | Notes |
|---|---|---|
| Pixel dimensions | 213 × 213 px | Square — not passport ratio |
| DPI metadata | 200 DPI | Embedded in the file, not just implied by pixel count |
| Background | Plain white | No shadow, pattern, or tinted wall |
| Format | JPG / JPEG | PNG and HEIC commonly fail upload validators |
| Colour | Often processed as grayscale-compatible | Verify on the live portal — some NSDL flows expect greyscale output |
| Face | Front-facing, neutral expression | Both eyes visible, no sunglasses or headwear unless religious |
The 213×213 pixel target is unusually small compared to passport or visa photos. That small canvas means compression choices matter more: over-compressing to hit a low KB ceiling can blur facial detail enough that a manual review flags the image as low quality, even when the dimensions and DPI metadata are technically correct.
NSDL's upload widget typically validates before the form advances to the next section. Error messages vary — "invalid image dimensions," "photo does not meet requirements," or a generic upload failure — but the underlying cause is often one of three things: wrong pixel count, wrong DPI tag, or file size outside the accepted range. When the message is vague, measure the exported file directly rather than trusting the preview inside your editing tool.
Applicants applying for a new PAN, a PAN correction, or a reprint through Protean should confirm the current spec on the live portal before submitting. Requirements can be revised between tax years, and this guide marks its spec data as UNVERIFIED for that reason. The numbers above reflect the published operator targets as captured in mid-2026; your application portal's own help text takes precedence if the two differ.
UTIITSL PAN photo requirements
UTIITSL operates its own PAN application portal with a separate upload pipeline. The photo spec is square like NSDL's, but the numbers are substantially larger.
| Requirement | UTIITSL target | Notes |
|---|---|---|
| Pixel dimensions | 640 × 640 px | Square — same shape as NSDL, different size |
| DPI metadata | 600 DPI | Much higher than NSDL's 200 DPI tag |
| Background | Plain white | Same general rule as NSDL |
| Format | JPG / JPEG | Same format restriction |
| Face | Front-facing, neutral expression | Same general framing expectations |
The 640×640 pixel requirement produces a file with roughly nine times the pixel area of NSDL's 213×213 target. That difference is not something you can fix with a simple resize in one direction — scaling a 213×213 export up to 640×640 does not recover detail that was never captured. Starting from a reasonably high-resolution source photo and cropping down to 640×640 produces a sharper result than upscaling a smaller export.
The 600 DPI metadata tag is the second place UTIITSL applications commonly fail. Many phone exports and casual editing tools leave DPI at 72 by default, or omit the field entirely. The image displays correctly everywhere, but UTIITSL's validator reads the embedded tag, compares it against the published 600 DPI requirement, and rejects the upload. Setting DPI at export time — not just resizing pixels — is a required step for this operator.
UTIITSL also enforces file size limits on upload. The exact KB ceiling can change; check the portal's current instruction text. If your 640×640 export exceeds the maximum, reduce JPEG quality in small steps rather than shrinking pixel dimensions, because changing pixel count moves you off the spec entirely.
Quick reference: NSDL vs UTIITSL at a glance
Keep this table visible while you prepare the file. The two columns are not interchangeable — pick one row and follow it end to end.
| Property | NSDL (Protean eGov) | UTIITSL |
|---|---|---|
| Shape | Square | Square |
| Pixel size | 213 × 213 px | 640 × 640 px |
| DPI | 200 | 600 |
| Background | White | White |
| Format | JPG | JPG |
| Typical failure if wrong operator | Dimensions too large; DPI too high | Dimensions too small; DPI too low |
| Portal identifier | proteanegov.in / NSDL branding | utiitsl.com / UTIITSL branding |
One square photo cannot satisfy both columns simultaneously. If you are unsure which operator you need and want to prepare ahead of time, take a high-quality source photo with even lighting and a plain background, then produce two separate exports — one at each spec — only after confirming the operator from the application URL. Preparing both takes a few extra minutes and avoids a last-minute scramble if you started on the wrong preset.
How to confirm which operator your application uses
Before opening any cropping tool, identify the operator. This single check prevents the most common category of PAN photo rejection.
- Read the browser address bar. NSDL applications typically run on Protean eGov domains. UTIITSL applications run on UTIITSL domains. The domain name is the most reliable indicator.
- Check the portal logo and footer. Protean/NSDL branding and UTIITSL branding appear consistently on their respective application pages, including on the photo upload step.
- Look at the application tracking page. If you already submitted and need to re-upload a photo, the track-application screen usually states which operator processed the form.
- Ignore third-party aggregator sites. Some commercial "apply for PAN" intermediaries route to one operator or the other without making the distinction obvious. Always follow through to the official operator portal before uploading a photograph.
- Do not assume from your city or state. Both operators serve applicants nationally. Geography does not determine which spec applies — the portal does.
If you prepared a photo for NSDL and later discover the application is on UTIITSL, discard the NSDL export and rebuild at 640×640 with 600 DPI. Scaling the smaller file up is not an acceptable shortcut. The same applies in reverse: a UTIITSL export cannot be downscaled to 213×213 without re-evaluating compression and DPI metadata for the NSDL target.
Step-by-step: preparing a compliant PAN card photo
This numbered process applies to either operator. Complete step 1 before any editing, because everything downstream depends on knowing which column of the spec table you are targeting.
- Confirm your operator using the checks above. Write it down — NSDL or UTIITSL — before you touch the source photo.
- Start from a clean source image. Use the original camera file if possible, not a screenshot or a photo already compressed for WhatsApp. Front-facing, even lighting, plain background, neutral expression, both eyes open.
- Crop to a square centred on the face. The face should occupy most of the frame without clipping the top of the head or chin. PAN photos are tighter and smaller than passport photos, but the same general framing rule applies: head upright, no tilt, no extreme close-up.
- Replace or clean the background to pure white. Off-white walls, cream paint, and light grey read as non-compliant once compressed. A background pass after cropping catches edge halos while there is still room to fix them.
- Export at the operator's exact pixel dimensions — 213×213 for NSDL, 640×640 for UTIITSL — and set the DPI metadata to match: 200 for NSDL, 600 for UTIITSL.
- Adjust JPEG quality until the file size falls inside the portal's KB range. Check the live portal for the current minimum and maximum. Compress in small steps and inspect at 100% zoom after each pass.
- Verify before upload. Open the file properties on your device. Confirm pixels, KB, and format. Zoom to 100% and check all four corners for background consistency. Only then upload to the application form.
Steps 5 and 6 are where most DIY attempts fail. A tool that crops correctly but leaves DPI at 72 produces a file that looks right and fails silently on upload. A tool that sets pixels correctly but over-compresses produces a file inside the KB range with visible softness that manual review rejects.
Following this pan card photo size complete guide step by step takes about ten to fifteen minutes the first time, and under five minutes on repeat once you know your operator and have a good source photo saved.
File size, format, and compression for PAN uploads
Pixel dimensions and DPI metadata are only two of the checks PAN portals run. File size in kilobytes is a separate gate — and it behaves independently of resolution.
Most government upload widgets enforce both a maximum and sometimes a minimum file size. A maximum prevents oversized uploads from slowing server processing. A minimum, where present, filters out files so heavily compressed that facial detail is no longer usable. The exact KB range is not identical between NSDL and UTIITSL, and it can be updated without a public announcement. Read the instruction text next to the upload field on the live form before you finalize compression.
Format: Export as JPG or JPEG. PAN portals, like most Indian identity upload flows, reject PNG, GIF, BMP, and HEIC. iPhone users shooting in HEIC should convert to JPG before any crop or compression step, ideally at the start of the workflow so every subsequent edit reads the same file.
Compression strategy: Start at a moderate JPEG quality — around 80% — and check the resulting KB size. If you are above the portal maximum, reduce quality in increments of five to ten points and re-check both KB and visual sharpness at each step. If you are below a stated minimum, increase quality slightly or verify that your pixel dimensions are correct — an undersized dimension export can produce an artificially small file that looks fine in a file manager but fails quality validation.
Grayscale and colour mode: NSDL's workflow has historically accepted or expected grayscale-compatible output in some application paths. UTIITSL's path typically works with standard colour JPG. If your export fails repeatedly despite correct dimensions and DPI, check whether the portal's help section mentions colour mode or grayscale, and whether your editing tool tagged the file with an unexpected colour profile. This is an edge case, but it appears often enough in forum reports to be worth checking before you retake the photo entirely.
For a deeper walkthrough of how JPEG quality interacts with KB size without destroying facial detail, see the dedicated guide on JPG quality versus file size tradeoffs — the same compression ladder applies to PAN uploads once your crop and background are locked.
Background, face, and expression rules
PAN photo background rules align with other Indian identity documents in principle — plain white, no clutter — but the smaller square format leaves less margin for error at the edges.
Background: The background must read as uniform white across the entire frame, including the corners. Shadow behind the shoulders, a visible wall texture, or a slight cream tint from indoor lighting all fail automated checks that sample pixel colour at the frame edges. If you shot against a light-coloured wall, run an explicit background replacement pass rather than assuming the wall is white enough.
Lighting: Even, front-facing light works best. A single overhead bulb casts shadows under the eyes and nose that read as dark patches after compression. Window light from the front, with the window behind the camera rather than behind you, is sufficient for a phone capture.
Expression and pose: Neutral expression, mouth closed, both eyes open and visible. No sunglasses. Head coverings for religious reasons are generally permitted if the full face remains visible from chin to forehead. Do not smile broadly or show teeth — the validators are less strict than passport offices on this point, but neutral is the safe default.
Glasses: If you wear glasses daily, keep them on for consistency with your other identity documents, provided there is no glare obscuring the eyes. Remove tinted lenses.
Recency: Use a recent photo that resembles your current appearance. PAN corrections for photo updates exist, but avoiding a mismatch at the outset saves a separate correction application later.
These rules overlap with passport photo guidance, but the output dimensions differ. Do not assume that a photo accepted for passport or passport photo rejected passport seva explained troubleshooting contexts will transfer directly to PAN without re-exporting at the square operator spec.
Common rejection reasons on NSDL and UTIITSL portals
Understanding why uploads fail helps you fix the right variable instead of retaking the photo from scratch each time.
| Rejection symptom | Most likely cause | Fix |
|---|---|---|
| "Invalid dimensions" or upload will not proceed | Wrong pixel count for your operator | Re-export at 213×213 (NSDL) or 640×640 (UTIITSL) |
| Upload accepts file then stalls at review | DPI metadata mismatch | Re-export with 200 DPI (NSDL) or 600 DPI (UTIITSL) |
| "File too large" | KB above portal maximum | Reduce JPEG quality; do not shrink pixels |
| "File too small" or quality error | Over-compression or wrong dimensions | Increase quality slightly; confirm pixel count first |
| Background error | Off-white, shadow, or halo at edges | Re-run background pass; inspect corners at 100% zoom |
| Generic failure with no detail | Wrong operator spec entirely | Confirm portal; rebuild for correct operator |
| Wrong format | PNG, HEIC, or other non-JPG export | Convert to JPG before upload |
NSDL rejections cluster around dimension and DPI mismatches because the 213×213 target is uncommon enough that generic "ID photo" presets rarely default to it. UTIITSL rejections cluster around DPI metadata and file size because the 640×640 export at 600 DPI produces a larger file that hits KB ceilings if compression is not tuned.
If the portal accepts the upload but the application later requests a photo resubmission, treat it as a manual review failure rather than an automated one. Manual review catches soft focus, visible background artefacts, and face framing issues that passed the automated gates. Zoom to 100% on the exported file and compare against the table above before you re-upload.
When the first re-export does not resolve the rejection, work through this sequence before retaking the photograph: reconfirm the operator; measure the actual saved file rather than the editor preview; check DPI metadata on an advanced properties tab; test upload in a second browser; and restart from the original camera photo if you have compressed the same JPG multiple times. If all measured properties match the published spec and upload still fails, capture the exact error message and check the operator's live help text — spec revisions occasionally roll out mid-year. Persistent soft-focus rejections after correct dimensions usually mean the source photo was too low-resolution; retaking against a plain wall in even daylight resolves those faster than another round of JPEG tuning.
Common mistakes when preparing a PAN card photo
- Using a passport photo without re-cropping. Passport photos are 35×45 mm rectangles — roughly a 7:9 ratio. PAN photos are squares. Stretching a passport crop to square distorts the face.
- Assuming one square size fits both operators. 213×213 and 640×640 are not approximations of the same spec. They are different targets for different portals.
- Setting pixels but not DPI. The file looks correct in every preview. The validator reads metadata and rejects it.
- Upscaling a small export. Enlarging 213×213 to 640×640 does not add detail. Start from the original high-resolution source.
- Compressing before cropping. Cropping after compression discards the file size you just tuned and forces a second compression pass with added artefacts.
- Trusting a generic "PAN photo" preset without checking the operator. Some third-party tools pick one spec and label it "PAN" without distinguishing NSDL from UTIITSL.
- Uploading a WhatsApp-forwarded image. Messaging apps re-compress photos in transit. Use the original file or a direct export.
- Ignoring the operator because of your location. Both operators serve all of India. City and state do not determine the spec.
- Reusing an old PAN photo for a new operator. If you applied through NSDL before and now apply through UTIITSL, rebuild the file even if the old photo looks fine.
- Skipping the 100% zoom check. Thumbnail previews hide halo edges, soft compression, and corner shadows that validators catch.
Each of these mistakes produces a file that appears acceptable at glance level. The pan card photo size complete guide verification step at the end of the preparation process exists specifically to catch them before upload, not after rejection.
How PAN photos differ from passport, Aadhaar, and driving licence uploads
Indian applicants often maintain a folder of "document photos" and reuse them across applications. That workflow works only when the target spec matches. PAN, passport, Aadhaar, and driving licence uploads frequently do not.
| Document | Typical shape | Typical pixels | Notes |
|---|---|---|---|
| PAN (NSDL) | Square | 213 × 213 px | 200 DPI; operator-specific |
| PAN (UTIITSL) | Square | 640 × 640 px | 600 DPI; operator-specific |
| Passport | Rectangle (7:9) | 630 × 810 px | 35×45 mm at 300 DPI |
| Aadhaar (when upload required) | Rectangle (7:9) | Varies; often passport-style | Many enrolments capture live — see aadhaar photo size |
| Driving licence (Sarathi) | Rectangle (7:9) | Passport-style photo plus separate signature | See driving licence photo signature |
The PAN row is the outlier in shape category only in the sense that both operators use a square — but they disagree with each other on size. Passport, Aadhaar upload scenarios, and Sarathi driving licence photos share a rectangular passport-style ratio even when their exact pixel counts and KB ranges differ.
If you already have a compliant passport photo, reuse the source image — not the passport export — and crop fresh to the square PAN spec for your operator. The background and lighting from a good passport source transfer cleanly. The exported passport file itself does not.
Applicants managing multiple document applications in the same month should process each photo against its own spec table rather than batch-converting one export to all targets. The convert photo to passport size complete process applies to rectangular documents; PAN square exports need the operator-specific workflow in this pan card photo size complete guide instead.
FAQ
What is the PAN card photo size for NSDL applications? NSDL (Protean eGov) typically requires a square photograph at 213 × 213 pixels with 200 DPI embedded in the file, a plain white background, and JPG format. Verify the current numbers on the live Protean portal before submitting, as specifications can change.
What is the PAN card photo size for UTIITSL applications? UTIITSL typically requires a square photograph at 640 × 640 pixels with 600 DPI embedded in the file, a plain white background, and JPG format. The pixel count and DPI tag are both checked independently of each other on upload.
Can I use my passport photo for a PAN application? Not as a direct upload. Passport photos use a 35×45 mm rectangular ratio; PAN photos are square at operator-specific pixel counts. Reuse the same source image and crop a fresh square export at the correct NSDL or UTIITSL spec rather than submitting the passport file.
Does DPI actually matter for a digital-only PAN upload? Yes, on many portal validators. Some checks read the DPI metadata field embedded in the JPG rather than inferring resolution from pixel dimensions alone. Match the operator's stated DPI — 200 for NSDL, 600 for UTIITSL — at export time.
What file format is required for PAN card photo upload? JPG or JPEG. Other common formats — PNG, HEIC, GIF — typically cause upload failures on both NSDL and UTIITSL portals. Convert iPhone HEIC files to JPG before cropping.
Why was my PAN photo rejected even though it looked fine? The most frequent causes are wrong operator spec (213×213 submitted to UTIITSL or the reverse), missing or incorrect DPI metadata, file size outside the KB range, and backgrounds that read as off-white after compression. Measure the file properties directly rather than relying on screen preview.
Can I prepare a PAN card photo on my phone? Yes. Most browser-based preparation tools work on mobile. Confirm the exported file's pixel dimensions and KB size using your phone's file details view, since some mobile interfaces hide this information behind an extra tap.
How much does it cost to resize a photo for PAN? Browser-based tools can complete the crop, background, and compression steps at no cost. Paid tiers on some services add watermark removal or batch export, not better accuracy against the operator spec.
How long does the pan card photo size complete guide process take? A first-time preparation — confirm operator, crop, background, compress, verify — typically takes ten to fifteen minutes. Repeat preparations with a saved source photo usually take under five minutes.
What background colour is required for PAN photos? Plain white with no shadow, pattern, or visible texture. Light grey, cream, or off-white walls often fail automated edge sampling even when they look white to the eye.
Can I reuse my PAN photo for an Aadhaar update upload? Only after re-exporting at the Aadhaar target spec, which is typically passport-style rectangular rather than square. The source image can be the same; the exported file cannot be shared without re-cropping. See the aadhaar photo size page for enrolment versus upload scenarios.
Does this pan card photo size complete guide apply to minor PAN applicants? Yes. Minor PAN applications through either operator use the same photograph upload requirements as adult applications. The framing and background rules are identical; only the applicant details on the form differ.
Fix it now
Processed on your device. Your photo is never uploaded.
Upload a photo to see the compliance checklist.
India Passport (ICAO 2026) specs are sourced from official notifications and may change. Always confirm against your portal before submitting. PhotoFix does not guarantee acceptance — we build to published requirements.
Upload your source photo and run the crop, background, and compression pass against the published spec before you touch the NSDL or UTIITSL upload field. Starting from a clean square crop on a high-resolution source takes less time than unwinding a rejection after the application is already in progress.
Whichever operator you confirmed — NSDL at 213×213 and 200 DPI, or UTIITSL at 640×640 and 600 DPI — the deciding factor is whether the exported JPG matches every column in the spec table, measured on the saved file rather than eyeballed on a preview screen. This pan card photo size complete guide is built around that measurement step because it catches the failures that look invisible at thumbnail size. Keep your original unedited source photo until the portal accepts the upload; every re-crop and re-compress pass is faster and cleaner when it starts from the camera file rather than an already-compressed export.
Related guides
More PhotoFix articles on the same problem or document type.
- ExplainerWhat is ICAO Doc 9303, and why India's photo size changedICAO passport photo standard explained — context for India's 35×45 mm size and the old 51×51 mm studio prints.
- Explainer"Face height 36–38mm" — what that actually meansChin to crown measurement for passport photo — what 36–38 mm means and how normal framing fails it.
- TroubleshootingPassport photo rejected at the PSK counter: every cause, diagnosedTold to retake at Passport Seva? Match your symptom to the cause — shadow, glasses, face size, or wrong dimensions — and fix it before you go back.