PAN vs Aadhaar vs Driving Licence Photo Requirements Compared

PAN, Aadhaar, and driving licence photos look similar on a phone screen but publish different pixel targets, aspect ratios, and upload rules — mixing them up is the fastest path to rejection on all three portals.

Key takeaways

• PAN photos are square at two different sizes depending on operator — NSDL uses 213×213 px at 200 DPI; UTIITSL uses 640×640 px at 600 DPI. Neither matches passport or Aadhaar upload dimensions.
• Aadhaar enrolment captures your photo live at the centre in most cases. When an update form asks for an upload, the target is usually passport-style 35×45 mm — not the PAN square.
• Driving licence applications on Sarathi need two separate files: a passport-style photo and a signature with its own stricter KB ceiling — often 20 KB for the signature alone.
• One source photo can produce compliant exports for all three document types, but each export must be rebuilt to its own spec. Reusing a PAN square for Aadhaar or DL without re-cropping fails automated validators.
• Background, expression, and lighting rules overlap across all three, but dimensions, DPI metadata, and file-size ranges do not. Treat each portal as a separate checklist.
• Verification before upload takes under a minute per file: pixel dimensions, KB range, format, background at 100% zoom, and confirmation that you matched the correct operator or state portal.

Why pan vs aadhaar vs dl photo requirements matter

Indian applicants routinely maintain a folder labelled "document photos" and reuse the same export across PAN correction, Aadhaar update, driving licence renewal, and passport applications. That habit works only when the underlying spec matches — and for these three document types, it usually does not.

The confusion starts with language. All three flows describe the requirement as "a recent passport-size photograph" in casual instructions, even when the technical validator expects something different. PAN portals want a square. Aadhaar update uploads often want a 35×45 mm rectangle. Sarathi driving licence photo fields accept a passport-style crop but pair it with a separate signature upload that has nothing in common with either PAN or Aadhaar rules.

Understanding pan vs aadhaar vs dl photo requirements side by side prevents the most expensive mistake: submitting first, discovering rejection days later, and retaking a photo you could have exported correctly from the same source file. The a full guide to passport photo hub covers passport-specific detail; this comparison focuses on where PAN, Aadhaar, and driving licence specs diverge and where they accidentally look the same.

Quick comparison: PAN vs Aadhaar vs driving licence

This table is the spine of the comparison. Read it once before you open any editing tool, identify which column applies to the application you are filing today, and ignore the others until you need them.

PAN photo requirements in detail

PAN applications route through two operators — NSDL (Protean eGov) and UTIITSL — and each publishes a different square spec. A file built for one operator fails on the other even when the background and expression are perfect.

NSDL targets: 213 × 213 pixels, 200 DPI embedded metadata, plain white background, JPG format. The canvas is small, so over-compression blurs facial detail quickly. Under-compression produces a file above the portal KB ceiling.

UTIITSL targets: 640 × 640 pixels, 600 DPI embedded metadata, same background and format rules. The larger canvas is more forgiving on compression but unforgiving on DPI tags — many phone exports default to 72 DPI and fail despite correct pixel count.

Neither PAN operator accepts a passport-ratio rectangle. If your existing export is 630 × 810 px from a passport workflow, it fails both PAN columns regardless of how clean the background looks. You need a fresh square crop centred on the face, then export at the operator-specific pixel and DPI targets.

Operator identification comes from the application URL and portal branding, not from your city or who recommended the site. Confirm NSDL versus UTIITSL before cropping; switching operators after the fact means rebuilding from source, not resizing the wrong export.

Aadhaar photo requirements in detail

Aadhaar behaves differently from PAN and driving licence uploads because enrolment is usually a live capture event, not a file upload.

New enrolment: UIDAI centres capture your photograph with a biometric camera during the appointment. You do not upload a prepared file in advance. Lighting, expression, and background are handled at the centre.

Update scenarios requiring upload: Some address, demographic, or photo update flows — especially online or through authorized partners — ask for a supporting photograph. Those requests typically specify a passport-style 35 × 45 mm frame, which maps to check the india passport photo size 35x45mm spec at 630 × 810 pixels and 300 DPI for digital submission.

The Aadhaar column therefore aligns with passport dimensions more often than with PAN squares. An applicant who prepared a PAN file for NSDL cannot upload it to an Aadhaar update form expecting compatibility. Re-crop the same source photo to rectangular passport ratio, clean the background again after the tighter crop, and compress to the form's KB range.

When instructions say "Aadhaar-size photo" on a third-party form, read that form's own help text rather than assuming PAN or DL rules. If the form links to UIDAI guidance, follow that. If it references passport dimensions, use the passport column of the comparison table above.

Driving licence photo requirements in detail

Sarathi and Parivahan driving licence applications introduce a second upload type that PAN and Aadhaar do not require: a signature file separate from the photograph.

Photo field: Typically passport-style — plain white background, neutral expression, front-facing, both eyes visible. Pixel targets vary by state RTO portal, but the visual rules match passport photos closely enough that a correctly exported 630 × 810 px file often passes — after you confirm the current state notification.

Signature field: A scanned or photographed signature on white paper, cropped tightly, compressed to a strict KB ceiling. Many state portals enforce a 20 KB maximum on the signature alone — far tighter than photo limits. Applicants who pass the photo upload still fail the application on signature size.

The driving licence row is therefore two checklists, not one. Preparing "a driving licence photo" without the signature — or reusing a passport photo while ignoring signature compression — produces incomplete applications or rejections on the second upload field.

State variance matters. Karnataka, Maharashtra, Tamil Nadu, and other RTO portals may phrase requirements differently or adjust KB ranges between notification cycles. Always read the live Sarathi page for your state before export, not a generic blog screenshot from a previous year.

Where the three specs overlap — and where they do not

Background colour, neutral expression, front-facing pose, and plain clothing rules are similar across PAN, Aadhaar upload scenarios, and driving licence photo fields. If your source capture has harsh shadows on the face, visible patterns behind your head, or sunglasses, fixing the capture helps every downstream export.

Dimensions do not overlap. PAN squares never satisfy Aadhaar or DL photo fields without re-cropping. Passport-style rectangles never satisfy PAN without a new square export. DPI metadata tags differ by operator and must be set at export time, not assumed from pixel count alone.

File size in KB is an independent gate on every portal. A photo at correct pixels can fail because it is 8 KB (too compressed) or 180 KB (too large). Each form publishes its own range; middle-of-range is safer than hugging either extreme.

File size, format, and compression compared

Export JPG for all five rows. PNG, HEIC, and BMP cause upload failures on most Indian government widgets. iPhone users should convert HEIC to JPG at the start of the workflow so every subsequent edit reads the same file.

Compression strategy is identical in principle: adjust JPEG quality in small steps, check KB after each pass, zoom to 100% on the face before accepting the result. The difference is which pixel canvas you are compressing — 213×213, 640×640, 630×810, or a tight signature crop.

Background and face rules across all three

Plain white background is the consistent rule, but automated validators differ in strictness. A cream-coloured wall that looks white on a phone screen may read as off-white once compressed, triggering rejection on PAN, Aadhaar, or Sarathi photo fields alike.

Face height within the frame follows passport-style guidance for Aadhaar uploads and DL photos — roughly 70% of frame height, head centred, no tilt. PAN square crops are tighter; the face should fill most of the square without clipping the crown or chin.

Expression must be neutral with mouth closed and both eyes open. Religious headwear is permitted when it does not obscure the face; sunglasses and hats are not. Glasses are allowed on most portals if there is no glare obscuring the eyes — verify on the live form if your application is strict.

Common mistakes when mixing PAN, Aadhaar, and DL specs

• Uploading a PAN square to an Aadhaar update form because both were described as "ID photos" in informal instructions.
• Scaling a 213×213 PAN export up to 640×640 for UTIITSL instead of re-exporting from source — upscaling does not recover lost detail.
• Reusing a passport photo file for PAN without a new square crop — validators check aspect ratio before background quality.
• Passing the DL photo upload but ignoring the signature until the final submission step — the signature KB cap catches most applicants off guard.
• Assuming state driving licence rules match a neighbour state's Sarathi page — KB limits and pixel wording change between RTO portals.
• Trusting DPI defaults from phone cameras — 72 DPI exports fail UTIITSL and some strict passport-style validators even at correct pixel dimensions.

Each mistake produces a rejection that looks arbitrary until you measure the file. Applicants who hit passport photo rejected passport seva (14) after reusing the wrong crop for a different document type see the same pattern: the photo looked fine on screen and failed one numeric check the portal never explained in plain language.

One source photo, three compliant exports: workflow

1. Capture once in even daylight against a plain wall — front-facing, neutral expression, both eyes open, no filters.
2. Identify today's target — PAN operator, Aadhaar upload, or DL photo plus signature — before opening an editor.
3. Crop to the target aspect ratio — square for PAN, rectangle for Aadhaar upload and DL photo, tight rectangle for signature.
4. Background pass after crop — replace or clean to pure white; check all four corners at 100% zoom.
5. Export at exact pixels and DPI for the target column in the comparison table.
6. Compress to KB range in small quality steps; verify face sharpness after each pass.
7. Rename files clearly — pan-nsdl-213.jpg, aadhaar-update-630x810.jpg, dl-photo.jpg, dl-signature.jpg — so you do not upload the wrong export under time pressure.

This workflow is the practical answer to pan vs aadhaar vs dl photo requirements for busy applicants handling multiple documents in the same month. The capture happens once; the exports are separate; the verification step is non-negotiable for each file.

Operator and portal checks before you upload

PAN: Read the domain — Protean/NSDL versus UTIITSL — and match the square spec column before export.

Aadhaar: Confirm whether your flow requires live centre capture or an uploaded file. If upload, treat the spec as passport-style unless the form states otherwise.

Driving licence: Open your state Sarathi portal, read both photo and signature help text, and prepare two files. Test signature KB separately — it is the usual failure point.

Keeping a one-page checklist taped to your monitor beats re-learning these differences every tax season or licence renewal cycle.

NSDL versus UTIITSL: why two PAN columns exist

Income Tax Department PAN services split across NSDL (Protean eGov) and UTIITSL decades ago, and neither operator migrated to a unified photo validator. That legacy architecture is the reason pan vs aadhaar vs dl photo requirements include two PAN columns where Aadhaar and driving licence each have one.

NSDL's smaller 213×213 canvas compresses aggressively. Applicants exporting from high-resolution phone photos must downscale carefully — a single heavy compression pass can blur iris detail enough that manual review flags the upload even when automated dimension checks pass. UTIITSL's 640×640 canvas is more forgiving on facial sharpness but less forgiving on metadata: the 600 DPI tag is non-negotiable on many upload paths.

Switching operators mid-application — starting on a third-party aggregator that routed to NSDL, then completing on UTIITSL after a correction notice — catches people who prepared only one square export. Keep both square masters if your PAN history spans both operators.

Aadhaar centre capture versus online upload: two workflows

Confusing centre capture with upload requirements causes unnecessary editing. If your Aadhaar task is new enrolment, skip file preparation entirely and focus on appearance at the appointment: plain clothing, neutral expression, hair off the face if possible, no heavy filters on skin.

When UIDAI or an authorized partner requests an uploaded photograph, the workflow converges with passport-style editing. The rectangular crop, white background, and KB compression sequence matches passport more closely than PAN. Applicants comparing pan vs aadhaar vs dl photo requirements sometimes miss this split because marketing pages lump all three under "government ID photo."

Online update forms may also specify maximum and minimum KB separately from pixel dimensions. A rectangular export at correct 630×810 pixels can still fail if compressed to 12 KB — below a stated minimum — or 90 KB — above maximum. Read the upload widget help text character by character before finalizing compression.

Sarathi state variance: why the DL row has footnotes

Parivahan and Sarathi unify much of India's driving licence stack, but state RTO portals still publish notification-specific photo and signature rules. A Karnataka applicant and a Maharashtra applicant may see different KB ceilings or dimension wording in the same calendar month.

The photo field generally follows passport-style visual rules — white background, neutral face, no sunglasses — even when pixel targets differ slightly. The signature field is where variance hurts most: a 20 KB cap in one state and a 30 KB cap in another means you cannot reuse a signature export prepared for a relative in a different state without re-checking.

Always screenshot the help panel next to each upload field on the day you apply. Notification PDFs from previous years circulate in WhatsApp groups with outdated numbers.

DPI metadata: the invisible rejection layer

Pixel dimensions are visible in every file manager. DPI is not — and PAN (especially UTIITSL), passport-style Aadhaar uploads, and many Sarathi photo fields read embedded DPI tags during validation.

A file labelled 630×810 with 72 DPI default from a phone re-save fails some validators. A 640×640 PAN export with correct pixels but 200 DPI fails UTIITSL expecting 600. Fixing DPI means re-exporting from the cropped master with the tag set at save time — changing pixels alone does not update metadata on all tools.

If your editor lacks DPI controls, use one that exposes export metadata or verify with a desktop inspector before upload. This layer explains many "dimensions look correct but upload failed" reports across all three document types.

Grayscale, colour mode, and edge cases on PAN uploads

NSDL paths have historically accepted or expected grayscale-compatible output on some application types. UTIITSL generally expects standard colour JPG. If your export fails repeatedly with vague errors despite correct square dimensions, check whether the portal mentions colour mode — an unexpected CMYK or greyscale profile embedded by an editing tool can trip validators that assume sRGB.

This is an edge case, not the median failure, but it appears often enough in operator forums to include in a thorough pan vs aadhaar vs dl photo requirements comparison. When in doubt, export sRGB colour JPG from a clean pipeline rather than re-saving through multiple apps.

Comparison disclosure: how we evaluate specs

PhotoFix publishes this comparison and operates an in-browser passport and ID photo tool. We are not affiliated with NSDL, UTIITSL, UIDAI, or state RTO authorities. Numbers here reflect published operator targets captured in mid-2026 and are marked UNVERIFIED because portals change without always updating public help pages.

When our tool's preset matches a column in the comparison table, we still recommend measuring your exported file before upload — the same verification standard we apply to third-party tools in other comparisons on this site.

Practical checklist before any upload

Print or save this ordered checklist per document type:

PAN (after confirming operator): square crop → white background → operator pixels → operator DPI → JPG → KB range → verify all properties.

Aadhaar upload (not centre capture): confirm upload required → rectangular 7:9 crop → white background → typically 630×810 at 300 DPI → JPG → KB range → verify.

Driving licence: read state Sarathi help → photo branch as rectangular → signature branch separately → both JPG → both KB ranges → verify both files independently.

Skipping any line produces the rejections mapped throughout this guide. The checklist takes two minutes per file and replaces guesswork.

When retaking beats re-exporting

Re-exporting from source fixes dimension, DPI, KB, and background failures. Retaking fixes capture failures: motion blur, closed eyes, extreme head tilt, glare on glasses, or a patterned shirt that bleeds through background removal.

If you zoom to 100% on the face and detail is gone — not because of one bad compression pass but because the original was a forwarded WhatsApp image — no PAN square or Aadhaar rectangle rescues the capture. Retake once with even light, then run the branching workflow from the new original.

Historical context: why specs diverged

PAN digitization predated modern smartphone camera defaults. NSDL's 213×213 target reflects early web upload constraints. UTIITSL's later 640×640 path reflects higher-resolution capture norms without harmonizing with NSDL. Aadhaar's live biometric capture sidesteps file upload for most enrolments. Sarathi merged legacy state systems with dual photo-and-signature uploads.

Understanding that history does not change today's validators, but it explains why applicants expect one "India ID photo size" and encounter four different technical targets. pan vs aadhaar vs dl photo requirements is really a comparison of four upload pipelines that happen to involve the same human face.

FAQ

What is the difference between PAN and Aadhaar photo size? PAN uses a square — 213×213 px on NSDL or 640×640 px on UTIITSL — with operator-specific DPI tags. Aadhaar update uploads typically use a passport-style 35×45 mm rectangle, not a square. New Aadhaar enrolment usually does not use an uploaded file at all.

Can I use the same photo file for PAN and driving licence? Not without re-exporting. PAN requires a square crop at operator-specific pixels and DPI. Driving licence photo fields expect a passport-style rectangle. The same source image works; the same exported file does not.

Does Aadhaar accept a PAN card photo? No for most upload scenarios — PAN exports are square and the wrong aspect ratio for Aadhaar update forms that expect passport-style dimensions. Re-crop from your original source photo.

Why does my driving licence application reject the photo but not the signature, or vice versa? Photo and signature are validated separately with different KB rules. A 24 KB photo may pass while a 45 KB signature fails on portals with a 20 KB signature cap, and the reverse happens if the photo exceeds its ceiling.

Which PAN operator am I on? Check the application URL and portal branding — Protean eGov for NSDL, UTIITSL for the alternate operator. The operator determines which square spec applies, not your location.

Is live Aadhaar centre capture the same spec as online upload? Centre capture follows UIDAI biometric guidelines at capture time. Online uploads follow the form's published file requirements, which often mirror passport dimensions. They are related in appearance rules but not identical in workflow.

What format do all three accept? JPG or JPEG for uploaded files. Avoid PNG, HEIC, and BMP unless a specific form explicitly allows them — most do not.

How do I check DPI metadata? On desktop, view file properties or use an image inspector that shows embedded DPI. On mobile, use a file-details app or re-export through a tool that lets you set DPI at save time. Pixel dimensions alone do not prove DPI is correct.

Can PhotoFix export all three from one source? PhotoFix handles passport-style crops and compression in-browser. For PAN squares and DL signatures, use the preset that matches your target portal, verify pixels and KB yourself, and produce separate downloads per document type.

How long does it take to prepare three exports from one photo? About fifteen to twenty minutes the first time — mostly verification and compression passes. Repeat runs drop below ten minutes once you know your operator and state portal targets.

Does pan vs aadhaar vs dl photo requirements change every year? Operators and UIDAI update guidance periodically. The comparison structure stays stable — square PAN, rectangular Aadhaar uploads, dual DL uploads — but exact KB ceilings and pixel wording should be confirmed on the live portal before submission.

Fix it now

Open your source photo, pick the document type you are filing today, and export to that column's spec only — not the file you used last time for a different document. Measure pixels, KB, and background at 100% zoom before upload. One correct export beats three rejected shortcuts.

Operator portals update KB ceilings without press releases — confirm live help text each application season before treating any comparison table as permanent gospel.

Square PAN exports and rectangular passport-style exports can share lighting and expression rules but never share the same pixel file without re-cropping from source.

Sarathi signature uploads punish applicants who budget all their editing time on the portrait — treat signature compression as a first-class step, not an afterthought.