Methodology

Every number on this site — a pixel dimension, a kilobyte range, a compression target — comes from somewhere, and this page documents where. It exists so you can judge for yourself whether to trust a specification before you submit an application with it.

1. What counts as an official source

For exam specifications we accept only two source classes, in this order of authority:

• The official notification PDF for the current recruitment cycle, published by the conducting body (SSC, UPSC, IBPS, NTA, IIT GATE organising institute). This is always the final word.
• The live application portal's own upload instructions — the on-screen rules shown at the moment of upload, which occasionally differ from the notification and, when they do, are what the portal actually enforces.

Third-party blogs, coaching-site articles and forum posts are never used as sources. They are how wrong specs propagate.

2. The verification process

Before any specification enters a tool, it goes through the same four steps:

• Locate the current cycle's notification or portal instruction and extract the exact wording — pixel dimensions, file-size range, format, and any background or ink-colour rules.
• Record the value in a single configuration file with a lastVerified date. Tools read from this one place, so a correction updates every page at once.
• Surface that date in the tool's interface. If a date looks stale relative to your exam cycle, treat that as a prompt to cross-check the notification.
• Re-verify when a new cycle's notification is published, or immediately when a user reports a mismatch via the contact form.

3. How ambiguity is handled

Notifications are sometimes imprecise — a size range with no pixel dimensions, or "JPG" with no colour-mode rule. When that happens we apply the strictest reasonable interpretation (the one most likely to pass automated portal validation), and the tool aims for the middle of any permitted range rather than its edges, so minor differences between devices never push a file over a limit.

4. How the image math works

Our tools share one processing engine, and its behaviour is the same everywhere:

• Decoding: images are decoded in your browser, EXIF orientation is corrected, and very large photos are downscaled in halving steps to stay inside mobile canvas memory limits without visible quality loss.
• Resizing: the image is fitted to the exact target pixel dimensions required, never stretched — aspect is preserved by cropping or padding as the preset demands.
• Hitting a KB target: JPEG quality is binary-searched — the tool repeatedly re-encodes at higher or lower quality until the file lands inside the required range, then keeps the largest passing file. You get the sharpest image the limit allows, not just any file under it.
• Signature clean-up: ink-boost raises contrast, whitening flattens off-white paper to pure white, and grayscale removes colour casts — standard image operations applied locally, nothing more.

None of this involves a server. The engine runs in your browser, which is also why we can never see your files — there is no transmission step in the pipeline at all.

5. Corrections

When a verified value turns out to be wrong or out of date, the fix ships within days: the configuration value is corrected, the lastVerified date is updated, and the change takes effect across every affected tool simultaneously. Spec reports are the highest-priority category of message we receive — if you spot a mismatch with an official notification, send it in with a link to the source and it jumps the queue.

6. What this site will not claim

We do not claim affiliation with any examination body, and we do not guarantee acceptance of any upload — portals change rules mid-cycle, and the official notification for your specific cycle always outranks anything written here. What we do claim is narrower and checkable: every specification has a named source class, a verification date you can see, and a correction path that works.