Resize Image to 30KB

A surprising number of government exam portals, bank account opening forms, and scholarship applications specify a 30 KB ceiling for passport-size photos and signature scans. The figure is not arbitrary: these portals were often designed when server bandwidth was expensive and form storage was allocated in fixed blocks. A 30 KB cap keeps total submission packages under a few hundred kilobytes even when dozens of attachments are collected per applicant.

The practical result is that applicants frequently encounter a hard upload wall — the portal refuses the file outright rather than auto-scaling it. Unlike a generous 200 KB or even 100 KB ceiling, 30 KB leaves very little room for a casual smartphone crop-and-upload workflow. A fresh photo taken on a modern phone produces a JPEG of 2 to 5 MB; reaching 30 KB requires deliberate compression, not just a quick resize.

Understanding that constraint upfront saves repeated failed submissions. The tool above applies the right combination of dimension reduction and quality adjustment automatically, targeting 30 KB while keeping the image recognisable enough to pass the identity check that follows upload.

At 30 KB, the relationship between pixel count and quality is tighter than at higher targets. A useful rule of thumb: a 600x800 pixel JPEG at quality 75 typically lands between 28 and 38 KB for a standard portrait photo with moderate background complexity. That makes 600x800 the natural anchor for passport-size images at this target. For signature scans — which are mostly white background with dark strokes — the same dimensions at quality 80 to 85 usually compress well below 30 KB because the entropy in the image is low.

If dimension reduction alone is insufficient — for example when the source has high background texture — quality must come down further. The range between quality 60 and 72 is where most 30 KB targets land for photographic content. Below quality 55 the 8x8 block artefacts inherent to JPEG become clearly visible at normal display sizes, so that is the practical floor. Anything above quality 80 at 600x800 risks overshooting 30 KB for photos with busy backgrounds.

For PNG sources, the conversion path matters. A PNG of a photo is almost always larger than an equivalent JPEG; converting to JPEG before applying compression is necessary. A PNG of a signature or line drawing, however, compresses much more efficiently if kept as PNG — a 600x200 black-on-white signature PNG can reach under 10 KB without any lossy step. The tool handles this automatically by detecting whether lossy or lossless output is more efficient for the given source.

File-size rejection is the most obvious failure, but not the only one. Portals that cap at 30 KB often enforce additional constraints simultaneously. Dimension minimums are common: a photo that is only 200x250 pixels may compress easily under 30 KB but will be rejected because the portal requires at least 300 pixels on the short edge for identity verification purposes. Always check dimension requirements alongside the size cap.

Format restrictions add another layer. Many exam portals specify JPEG only and will reject a PNG even if its file size is under 30 KB. Similarly, some portals reject progressive JPEGs — images saved with the progressive scan order rather than baseline — because older form-processing software reads only baseline JPEG. The tool saves in baseline JPEG by default for exactly this reason.

A less obvious rejection cause is metadata. Some portals run validation scripts that check EXIF data, ICC colour profiles, or thumbnail thumbnails embedded in the JPEG header. A photo stripped to bare image data often passes validation that the same photo with full EXIF fails, even at identical visual quality. Removing metadata also reduces file size by a small but sometimes decisive margin — a heavily tagged JPEG may carry 20 to 60 KB of EXIF and thumbnail alone.

Finally, colour space mismatches cause rejections on a minority of portals. A JPEG saved in Adobe RGB or a wide-gamut profile can display with shifted colours in the portal preview, which sometimes triggers a manual rejection during document verification. Saving in sRGB, which the tool does by default, avoids this category of problem entirely.

When a portal says the maximum file size is 30 KB, it almost always means 30 kilobytes in the colloquial sense: 30 times 1000 bytes, which is 30,000 bytes. This is the definition used by operating system file managers on Windows and macOS for display purposes, and by the majority of web form validators.

The technically precise unit for 1024 bytes is one kibibyte, abbreviated KiB. A 30 KiB limit would be 30 times 1024 bytes, which equals 30,720 bytes — about 2.4 percent larger than 30,000 bytes. In practice, portal validators almost never use the IEC binary definition for file-size caps even when they write KB in the requirement text.

The conservative approach is to target 30,000 bytes or slightly below when the portal specifies 30 KB, because validators typically compare the raw byte count of the uploaded file against a stored threshold. The tool targets the decimal kilobyte definition and tries to land just under the threshold, providing a small buffer for any rounding the portal validator applies.

The most common scenario for a 30 KB portal upload is filling out a form on a phone immediately after taking a photo. The photo app produces a multi-megabyte JPEG; the portal rejects it; the applicant searches for a solution while the form timer counts down.

The fastest path on any smartphone browser is to open the tool on this page, tap the upload area, select the photo from the gallery, and let the tool compress it client-side. Because all processing happens in the browser rather than on a server, the compressed file is available within a few seconds regardless of connection speed, and no image data leaves the device.

After compression, the tool offers a download button. On iOS, tapping download saves the file to the Files app under Downloads; on Android it saves to the Downloads folder. From there, returning to the portal upload dialog and selecting the compressed file from Downloads completes the workflow. The entire process typically takes under a minute.

If the portal opens a camera picker directly rather than a file picker — common on older Android WebViews — the workaround is to download the compressed file first, then manually navigate to the file picker option in the portal upload dialog. Most modern portals support both paths, but the file picker option is the reliable one when working with pre-compressed images.

The four most common portal size caps in the 20 to 100 KB range each represent a different set of trade-offs. At 20 KB, dimension reduction to 400x600 or smaller is almost always required for photographic content, and quality typically drops to the 55 to 65 range where compression artefacts are visible on close inspection. At 30 KB, 600x800 pixels remains achievable at quality 65 to 72, keeping the image acceptable for identity verification. At 50 KB, quality can stay in the comfortable 72 to 80 range at the same dimensions, producing a noticeably cleaner result.

The jump from 30 KB to 100 KB is large enough that dimension reduction often becomes optional for phone photos. At 100 KB, a 1200-pixel-wide photo at quality 80 typically lands well within budget, preserving enough resolution that the image looks crisp on any standard display.

If a portal accepts up to 50 KB, there is rarely a good reason to target 30 KB instead — the extra headroom goes directly into visible image quality. Conversely, if a portal caps at 20 KB and 30 KB gives a clear rejection, the 20 KB tool provides a target-specific workflow with appropriate default settings. Using the right target avoids both unnecessary quality loss and unnecessary re-uploads.

Signature images behave very differently from passport photos under compression, and a few preparation steps before compression make a significant difference to the final file size and legibility. The background colour has the largest single impact on file size. A pure white background gives JPEG encoding the lowest entropy to work with, because large uniform regions compress to almost nothing. A slightly off-white or cream background — common when signing on paper under warm lighting — increases entropy enough to add two to five kilobytes to the final file. Photographing the signed document on a flat surface under diffuse overhead light rather than angled sunlight reduces background texture and produces a cleaner source for compression.

For scanning, 150 DPI in greyscale mode is sufficient for most portal submissions that require a signature image. A 200x60 mm signature area scanned at 150 DPI produces a 1181x354 pixel greyscale image; converted to JPEG at quality 80, this typically lands between 12 and 22 KB. Colour mode at the same DPI produces a file roughly three times larger because the encoder must store separate chroma channels. If your scanner defaults to colour, switching to greyscale before scanning the signature eliminates those channels entirely.

Dimension requirements for signature images vary by portal. The most common specifications are 800x200 pixels, 600x200 pixels, and 140x60 pixels — the last is used by several Indian university entrance portals. Always check the dimension constraint alongside the size cap, because an oversized signature image may be rejected on dimension grounds even if its file size is well under 30 KB. If the portal specifies a minimum dimension and your signature scan is smaller, scale the canvas up with a white fill rather than stretching the stroke pixels, which would blur the signature.

When a source image will not fit under 30 KB, there are two dials available: pixel dimensions and JPEG quality. The general principle is to reduce dimensions before reducing quality. Halving both dimensions reduces file size by approximately 75 percent — a four-to-one reduction — while halving JPEG quality from 80 to 40 reduces file size by only about 50 percent at the cost of severe blocking artefacts across the entire image. Dimension reduction preserves edge sharpness because each remaining pixel still carries its full colour precision; quality reduction smears edges because it introduces quantisation noise in 8x8 pixel blocks.

A practical decision rule: if the source image is larger than 1200 pixels on its longer edge, reduce to 800x1067 pixels first and then check whether the file is already under 30 KB before touching quality. For a portrait with a plain background, 800x1067 at quality 78 typically produces 25 to 32 KB. For a photo with a busy or textured background — patterned wallpaper, outdoor foliage — quality may need to come down to 68 to 72 to reach the target even at those dimensions.

The interaction between resolution and content complexity explains why two photos at identical settings can produce very different file sizes. Entropy — the amount of unpredictable variation in pixel values — is what the JPEG encoder is actually compressing. A low-entropy source such as a face against a plain studio backdrop compresses further at any given quality setting than the same face against a patterned backdrop. When the portal allows a modest overrun — for instance a 30 KB label but a 32 KB hard limit in the validator — keeping quality one step higher is always preferable. The visual difference between quality 72 and quality 78 at 600x800 pixels is small but real, and the identity check that follows submission benefits from the cleaner result.

After compression the file shows as under 30 KB on your device, yet the portal continues to reject it. The first step is to verify the exact byte count rather than the rounded display value. Windows Explorer shows size on disk, which rounds up to the nearest storage allocation block and can appear larger than the actual byte count. To check the raw byte count on Windows, right-click the file, select Properties, and read the Size field rather than Size on disk. On macOS, press Command-I and read the number in parentheses. The portal validator compares against the raw byte count, so the rounded display figure is the wrong number to check.

The next step is to confirm that the portal is reading the file you downloaded rather than a cached version. Some portals read the file from a temporary browser cache path rather than re-reading from the file picker. If you compressed the file and are uploading in the same browser session, the portal may pick up an older cached version. Opening a private or incognito window and repeating the upload clears that path. Similarly, renaming the compressed file before upload resolves a failure on portals whose validators reject file names that do not end in .jpg in lowercase — a surprisingly common implementation on older government form systems.

If the file is close to but still over the target after all of the above, EXIF metadata is the most likely remaining cause. A JPEG straight from a phone camera can carry 20 to 60 KB of embedded GPS coordinates, camera model data, a full-resolution thumbnail, and ICC colour profile — none of which is visible in the image. Stripping metadata using any JPEG optimiser and re-uploading typically closes a three to six kilobyte gap. Finally, if the result from one browser sits just above the threshold, try the same compression in a different browser: the Canvas API JPEG encoder varies between Chrome, Firefox, and Safari, and a quality setting of 0.75 can produce slightly different byte counts across implementations.