Exam & application forms
Photo Under 50 KB — 200×230 px
Preset and ready: drop a file and the output lands under 50 KB as JPEG, capped at 200×230 px — processed entirely in your browser.
Drop your image here or browse
JPEG, PNG, WebP — everything stays on your device
Why this exact limit matters
This is the 50 KB ceiling of the IBPS photograph rule (20–50 KB, 200×230 px), locked together with the pixel box. Choosing the top of the band instead of the bottom is deliberate: mid-band output keeps maximum distance from both rejection edges and the encoder responds with near-maximum quality — the safest version of an already-passing file.
These portals enforce their limit at the byte level, so the only reliable approach is to work backwards from the number itself and let the encoder find the best quality that fits underneath it. 50 KB is a tight limit, typical of official upload forms, and this page is preset to exactly that ceiling.
This page locks both constraints for you: the output is capped at 200×230 px and at 50 KB total size, which is the combination application forms actually check.
How to compress to 50 KB
- Drop your image into the box above — it stays on your device.
- Confirm the target: under 50 KB as JPEG, dimensions set to at most 200×230 px.
- The MozJPEG encoder searches its quality range so the JPEG output lands just under your limit. Dimensions are set to at most 200×230 px.
- Preview the result, compare it with the original if you want, and download — the filename carries its actual size.
Tip: Before you upload, check whether your form also specifies pixel dimensions — if it does, fill in the max width and height here so both constraints are satisfied in one pass.
Measured: mid-band with maximum quality
Our 914 KB portrait test file through the 50 KB + 200×230 preset:
Source file
914 KB
1500×1800 JPEG
Size check
44.2 KB
mid-band, both edges clear
Dimension check
192×230
inside 200×230
Quality setting
q97
near-maximum
Quality 97 inside the box means the output is visually identical to a full-size passport photo at this scale. The practical takeaway across our IBPS measurements: at the 20 KB edge the encoder holds quality 89, at 50 KB it reaches 97 — both pass, but the mid-band file has margin against re-saves, portal recompression, and future re-uploads.
The band this preset tops out
| Form | Photo size rule | Dimensions | Format |
|---|---|---|---|
| IBPS PO & Clerk — photograph | 20–50 KB — 50 is the ceiling | 200×230 px | JPG |
| SSC CHSL — photograph | 20–50 KB | 200×240 px | JPG |
| SSC CGL — photograph | 20–50 KB | 275×354 px | JPG |
From the 2025–26 cycles. Both KB and pixel checks run independently — a file can pass one and fail the other, which is why this page locks them as a pair.
Frequently asked questions
Is 44 KB too close to the 50 KB ceiling?
It leaves 12% headroom, which survives a portal’s preview re-save. If you want more distance, type 45 as the target and the encoder lands just under that instead — the dimension box stays locked.
I also need the signature file — where do I make that?
The IBPS signature rule is 10–20 KB at 140×60 px; the matching preset page is linked in the table above. Process photo and signature separately — one form, two files, two locks.
Why does the preset cap at 200×230 rather than 200×240 like SSC CHSL?
This page implements the IBPS numbers. The boxes are close enough that an IBPS-shaped file often passes CHSL too, but if your form is CHSL, use a 200×240 cap to be exact — any dual-input page here accepts custom values.
My form rejected the file even though it shows the right size — what do I check?
Re-check the exact limit and the required format. Some portals quietly expect JPEG even when they say "image", and a few measure in 1,000-byte units rather than 1,024. Try the next lower round number here if the rejection persists.
Why JPEG and not another format for my upload?
JPEG is the most universally accepted image format on upload forms and gives the smallest files for photographs. If your destination accepts only "images", JPEG is the safe choice.
Is my image uploaded to a server?
No. All decoding and encoding runs locally in your browser via WebAssembly. There is no server-side pipeline, no storage, and no way for us to see your file.