Resize Image to 100KB

JPEG encodes images by splitting each frame into 8x8 pixel blocks, running a Discrete Cosine Transform on each block to express it as a sum of frequency components, then dividing each coefficient by a value from the quantization table. The quality parameter scales those divisors: at quality 95 they are tiny, almost every coefficient survives, and the file stays large. At quality 50 the divisors are coarse, most high-frequency detail rounds to zero, and the bytes drop sharply.

The relationship between quality and file size is not linear — it bends like a hockey stick. Moving from quality 92 to 80 typically cuts file size by 45 to 55 percent, because the discarded frequencies describe subtle texture variations the eye reconstructs anyway. Moving from quality 60 to 50 might save only another 15 to 20 percent, because the remaining coefficients encode gross structure — broad shapes and dominant colors — and the encoder needs almost all of them to keep the picture recognizable.

A concrete illustration with numbers: a 4032x3024 smartphone portrait at quality 95 might weigh 3.8 MB. At quality 85, around 1.4 MB. At quality 75, roughly 800 KB. At quality 65, about 500 KB. At quality 55, around 350 KB. Targeting 100 KB from that starting point at full dimensions requires quality somewhere between 30 and 40 — uncomfortable for portraits. Dropping to 1600 pixels on the long edge first brings the quality 85 version to roughly 200 KB, and the remaining gap to 100 KB then costs only a few more quality steps with no visible block artifacts.

WebP lossy encoding works on a similar principle but uses VP8 intra-frame prediction adapted for stills, typically reaching 25 to 35 percent better compression than JPEG at matched visual quality. The quality-versus-size curve exists but the knee sits lower: WebP at quality 75 roughly matches JPEG at quality 85 in visual fidelity while weighing 25 to 30 percent less. Because this tool outputs JPEG, a 100 KB JPEG carries a slightly larger quality penalty than an equivalent WebP file would — but JPEG remains universally accepted by the form portals that impose the 100 KB rule, which is the practical reason it stays the output format.

When pixel dimensions decrease, the resampling algorithm decides how each new, smaller pixel is computed from the original larger set. Two algorithms come up repeatedly in image tools: bilinear interpolation and Lanczos (also written Lanczos3 or sinc-windowed sinc).

Bilinear interpolation computes each new pixel as a weighted average of the four nearest pixels in the source image. It is fast and produces smooth output, but it applies a slight blur. For a portrait where the background already has shallow focus, bilinear downscaling is undetectable. For a document with 1-point rule lines or small serif type, the blur can make fine strokes disappear before the pixel dimensions fall low enough to hit the file size target.

Lanczos resampling uses a sinc function windowed to three lobes, called Lanczos3. It considers a wider neighborhood — a 6x6 kernel versus bilinear's 2x2 — and weights each neighbor with a curve that emphasizes nearby pixels and attenuates distant ones. The result preserves sharp edges and thin lines noticeably better than bilinear at the same output dimensions, at the cost of occasional mild ringing artifacts on very high-contrast transitions, such as thin dark text on a bright white page.

Browser canvas, which this tool uses, applies a high-quality downscaling method — typically a bicubic or Lanczos-equivalent approach on modern Chrome, Firefox, and Safari — rather than the nearest-neighbor algorithm that older tools sometimes defaulted to. In practice, photos resized through this tool show no staircase artifacts and preserve edges better than screenshots compressed through low-quality online tools. The rule of thumb: if you are compressing scanned certificates or receipts with 8-point text, run the original through this tool without pre-resizing and let the browser handle dimension reduction if it proves necessary. For portraits and product shots, the algorithm difference is academic.

Every JPEG from a modern camera or phone carries an EXIF block — a standard dating to 1995, designed by Fujifilm to embed shooting parameters alongside pixel data. The original implementation was small: aperture, shutter speed, focal length. The modern version includes GPS coordinates (latitude, longitude, altitude), a full-resolution embedded thumbnail (typically 160x120 pixels encoded as a second JPEG), the phone model and firmware string, the shooting time to milliseconds, and an ICC color profile.

A current iPhone EXIF block runs between 8 KB and 50 KB depending on whether the embedded thumbnail is present and how large it is. A Canon EOS R5 body writes around 6 to 15 KB. On a 5 MB source image this is background noise. On a 100 KB target file, 20 KB of metadata is 20 percent of the entire budget — 20 percent that could otherwise be spent on pixels.

Re-encoding through the browser canvas drops the EXIF block automatically, because the canvas decode step reads only pixel values, and the re-encode step writes a new JPEG containing only those pixels plus a minimal APP0 header of roughly 50 bytes. GPS coordinates, the embedded thumbnail, and the camera fingerprint all disappear. This is not a separate strip operation — it is a consequence of the encoding path, and it happens on every pass through the tool.

Two practical effects follow. The output file is smaller than a same-quality-setting encode that kept EXIF would be — which is why the binary search sometimes converges at a quality level slightly higher than you might expect from the raw size comparison. Any system that reads GPS or timestamp data from EXIF will also not find it in the output. For a form photo or profile picture that is fine. For a photo being handed to a photo agency asset management system that reads capture date from EXIF, this workflow drops that data permanently. Export the EXIF separately with ExifTool if it needs to travel with the compressed copy.

Example 1 — a university admission photo. Source: iPhone 14 Pro, portrait mode, 4032x3024 pixels, 5.2 MB JPEG. Target: 100 KB maximum, no minimum dimension stated by the portal. Strategy: quality reduction first. At quality 80 the re-encode produces 1.6 MB — 16 times over the limit. Enabling dimension reduction to 1600 pixels on the long side drops it to roughly 180 KB at quality 80. One further quality step to 70 lands at approximately 105 KB. Setting the target to 95 KB as a 5 percent margin accounts for KB-versus-KiB ambiguity. Result: 95 KB JPEG, 1600x1200 pixels, visually indistinguishable from the full-resolution version at form preview scale. EXIF and GPS stripped automatically.

Example 2 — a scanned income certificate. Source: flatbed scanner at 300 DPI, A4 page, 2480x3508 pixels, 11 MB TIFF converted to 4.8 MB PNG. Target: 100 KB. Converting PNG to JPEG first brings it to about 600 KB with no visible change. Enabling dimension reduction to 1240 pixels on the long edge drops it to roughly 140 KB. Setting quality to 65 reaches 96 KB. At quality 65 some thin horizontal rule lines in the document start to soften; if the form only needs legible text, 96 KB is fine. If specific fine print must stay crisp, keeping quality at 72 and accepting 115 KB, then re-running with dimensions reduced further to 1000 pixels, produces a cleaner result.

Example 3 — a product photo for an e-commerce listing. Source: studio shot, 3000x3000 pixels, white background, 7.4 MB JPEG from a professional camera. Target: 100 KB. Quality to 85 gives 1.1 MB. Dimension reduction to 1500 pixels cuts pixel count to one quarter and drops the file to 280 KB at quality 85. Quality down to 72 gives 102 KB. Quality to 70 gives 98 KB — safely within margin. Final output: 98 KB, 1500x1500 pixels. At quality 70 the white background holds its pure white with no visible banding, and the product edges stay clean. The studio lighting means there is little high-frequency texture for the quantization to discard, which is why this image survives quality 70 far better than a textured outdoor shot of similar pixel dimensions would.

Government exam registration portals. India's SSC CGL and UPSC civil services applications specify a 100 KB ceiling for the photograph and a 20 KB minimum for the signature scan. Candidates uploading a modern phone photo at 3 to 5 MB meet the error message immediately. The signature scan is the harder constraint: a clean 200x200 pixel PNG of a signature on white weighs only 8 to 12 KB naturally, but a photograph of a handwritten signature instead of a clean scan can weigh 400 KB, and the 20 KB floor means compressing to 5 KB to be safe is not an option — the target window is narrow on both ends.

University admission photo uploads. Most Indian central university systems cap the photo at 100 KB with a minimum pixel size around 150x200 or 200x200 pixels. International systems like Apply Texas or the Common App vary by document type, typically 100 KB to 2 MB. A student uploading from a recent smartphone has a 25 to 50 times gap to close before the file passes the upload check.

Marketplace seller verification. Amazon, Flipkart, and Meesho seller onboarding screens ask for business registration documents or PAN card scans under 100 KB per page. A scan from a multifunction printer at 200 DPI produces a 600 KB to 1.5 MB JPEG depending on page density. Quality reduction to the low 70s at full dimensions usually clears 100 KB for a single-column text document, though heavily formatted pages with logos and colored headers may need a dimension reduction step as well.

Government job portal profile photos. Several Indian state-level job boards — and national portals like the National Career Service — cap the profile photo at 100 KB, even though LinkedIn accepts files up to several megabytes. An applicant copying their LinkedIn headshot, already compressed to around 180 KB, still needs one pass through the tool before the government portal will accept it.

Hotel and airline loyalty program KYC. Several South Asian loyalty portals ask for a KYC photo under 100 KB as part of account verification. These portals are rarely updated and their error messages are vague — the upload often silently fails rather than reporting the file size. Knowing the 100 KB ceiling before attempting the upload prevents a second visit to the portal.

University ID card renewal systems. Many university systems issue digital ID cards from a selfie upload, and the card system enforces a 100 KB hard limit because the photo is stored in a database column rather than a file system — a column size set years ago when 100 KB was generous. The portal error message often says only 'file type not supported' when the real problem is file size, which is a consistent source of student confusion.

Microfinance and rural fintech document uploads. Some PMJDY-adjacent portals cap document uploads at 100 KB per page to stay within data allowances common on 2G and early 3G connections. The compression here is not primarily about server storage — it is about the end user's data bill when the uploaded file echoes back as a confirmation preview on the same connection.

The 100 KB limit shows up everywhere, and it is not an accident. Form portals inherited their number habits from the email era, when attachments were measured in kilobytes and server storage cost real money. A 100 KB ceiling was small enough to keep databases lean but large enough to accept a passport-style photo, so it spread from one government form to the next by copy-paste. Three decades later, the number is still there, sitting on upload buttons nobody has re-examined since.

The technology underneath explains why 100 KB can hold a decent photo at all. JPEG, released in 1992 by the Joint Photographic Experts Group, made it possible to throw away visual detail the eye barely registers. That is what the standard does: it trades exactness for size, and at 100 KB the trade still lands on the good side for anything viewed on a screen at normal size. The format has outlived every alternative aimed at it, and it remains the encoding this tool writes to.

Meanwhile the files people feed into these forms kept growing. A modern 12-megapixel phone camera produces a 4032×3024 image, and its JPEGs typically weigh 2 to 4 MB before any editing. So the gap between what the camera gives you and what the form accepts widened from small to absurd — roughly 40 to 1 — and almost everyone meets it for the first time at the worst possible moment, with the portal's red error message appearing five minutes before the application closes.

The clearest examples sit in exam and immigration paperwork. India's SSC and UPSC exam portals reject photographs and signature scans above 100 KB and often demand a minimum on the same file — usually 20 KB — which trips up anyone who compresses too far in the other direction. University admission systems in several countries cap the ID photo at the same mark, and marketplace seller-verification screens are frequent offenders too. The DS-160, the main US nonimmigrant visa application, allows a photo of at most 240 KB with a floor of 600×600 pixels, so applicants bouncing between forms meet different numbers under the same heading.

The bracket matters more than any single site, because 100 KB behaves differently from 20 KB. At 20 KB you are fighting for every pixel; at 100 KB you can usually keep full dimensions and pay for the reduction in quality alone. Knowing which bracket a form sits in tells you how much of your photo will survive the trip before you even open the tool.

One habit worth borrowing: open the form's help page and search it for the exact phrasing — 'maximum file size', 'in KB', 'dimensions' — before compressing anything. The wording tells you whether they check bytes, pixels, or both, and the answer changes which lever you reach for first. Forms that specify pixel dimensions separately from file size are the ones that punish careless resizing.

Concretely: a 12-megapixel photo reduced to around 1600 pixels on its long edge fits comfortably under 100 KB at a JPEG quality setting in the low 80s, and the result looks clean on a form review screen, a profile avatar, or a printed thumbnail. Keep the dimensions and lean only on quality, and you are typically fine down to 800–1000 pixels on the long edge. Below that, text on scanned documents starts to smudge before the file size ever complains.

Pixel count is the knob that moves size the fastest, though. Halving each side of an image cuts the pixel count to a quarter, and file size follows roughly in proportion — a 4000-pixel-wide photo dropped to 2000 pixels loses about 75 percent of its weight before quality even enters the conversation. Quality is the gentler knob: sliding from quality 92 down to 80 often halves the size with no visible change, while sliding below roughly 55 starts producing visible smudges around text and edges.

Content type shifts all these numbers. A portrait with a busy background spends its bytes on texture; a document scan spends them on sharp edges between black and white, which JPEG handles worse. The same 100 KB that holds a soft-focus selfie at 1600 pixels may only hold a crisp receipt scan at 1000. That is not the tool being inconsistent — it is what the content costs to describe.

When the file will not fit, which lever do you pull first? The order is simple. Quality reduction is free up to a point — a photo at quality 80 versus 92 looks identical on a form review screen but weighs half as much — so drop quality before anything else. Below roughly quality 55, artifacts start to show, and that is the signal to switch levers.

Then resize. Cutting the long edge to 1600 or 1200 pixels typically saves 40 to 60 percent on its own and is invisible for documents viewed on screen. Only resize to tiny dimensions as a last resort, because a photo below roughly 350 pixels on the short side can fail the portal's separate minimum-dimension check — most exam forms have one, and it fails silently: the upload accepts the file size, then the preview looks fine, then the application gets rejected days later for resolution.

The tool above handles this ordering for you by default. The optional resizing toggle decides whether the engine may shrink dimensions when quality reduction alone would not suffice; for most form photos, leaving it on produces the cleanest output. If the form states a pixel requirement, that is the one case where you should take manual control — lock the dimensions mentally, and if the tool reports it had to shrink below the floor, re-run with a different source file or accept the trade-off knowingly rather than discovering it at review.

If your source file is a PNG, converting to JPEG is usually the single biggest win available. PNG stores every pixel losslessly — it arrived in 1996 as an open replacement for GIF, built to never discard a byte — so a photograph exported as PNG can weigh 5 to 10 times its JPEG equivalent. A 6 MB PNG portrait re-encodes to a 600 KB JPEG with no visible difference, and from there the path to 100 KB costs almost nothing in quality.

The exception is screenshots and documents with flat colors, sharp text, or diagrams. PNG compresses those efficiently and JPEG adds ringing artifacts around letters — faint halos where dark strokes meet light backgrounds. So the rule of thumb is photos and scans go JPEG, screenshots with text stay PNG. If the form demands one format regardless, compress first, check the reported output size, and only then worry about the extension; most portals accept JPEG for photos and mean it.

A quick test before any conversion: zoom to 200 percent and look at the text. If the letters are still crisp, the file is a good candidate for staying PNG. If they already look slightly fuzzy, the content is photographic or the file has been JPEG-compressed somewhere upstream, and re-encoding as JPEG will lose nothing you can see.

The slider is preset to 100 KB, so the workflow is: drop in your image, press Compress, download. Under the hood the engine re-encodes the image as a JPEG and runs a binary search over quality settings — compress, measure, adjust, compress again — until it finds the version that stays at or under 100 KB while preserving as much visual quality as possible. You see the exact before-and-after sizes and dimensions before committing to the download.

One pass from the original is the whole trick. Every JPEG re-save multiplies the artifacts of the last one, and re-compressing an already-compressed file to chase a smaller target is how photos end up posterized and how text on scanned documents turns illegible. Keep the original file untouched, always compress from it, and never overwrite it with the compressed version — the original is your only route back if the first result misses the form's other requirements.

For a batch — a class of forty students' registration photos, say — the workflow is one pass per image at the same target, not one shared quality setting. Load the first image, compress at 100 KB, download, hit Reset, load the next; the tool keeps your last target so the setting sticks. A fixed byte target is what makes the batch consistent: two portraits shot minutes apart can differ 3x in raw size, so a single quality value that lands one at 80 KB puts the other at 200 KB. Targeting the byte count directly normalizes them automatically.

EXIF rotation is the more common culprit. A phone photo can look upright on screen while its stored pixels are sideways — the camera writes an orientation tag instead of rotating actual pixels, a convention that dates back to the EXIF metadata standard. Some portals measure dimensions on the stored orientation; others strip the tag themselves and display a rotated image. Re-encoding through the browser rewrites the pixels in their displayed orientation, which fixes both problems at once.

The size paradox catches people off-guard: re-saving an already-compressed JPEG at higher quality can produce a file larger than the original, because the decoder hands the encoder the previous compression's artifacts, and those cost more bits to describe than real detail did. It feels backwards, but it follows from how the format works — there is no uncompress step. Always compress from the original file in one pass, and check the reported output size before downloading rather than trusting the settings.

Both failures share a root cause: judging the file by what the preview shows instead of what the bytes say. The results panel in the tool shows the true post-compression size and dimensions — that pair of numbers is what the portal will measure, so read them there rather than eyeballing the image.

Nothing you process on this page is transmitted anywhere. The image is decoded and re-encoded by your own browser using its built-in canvas and encoding APIs — a technology that started in Apple's WebKit in 2004 and later became part of the HTML5 standard. No upload, no server, no trace; you could disconnect from the network after loading the page and the tool would keep working. That is the standard this site holds on every page.

It matters doubly here, because the files that carry a 100 KB rule are disproportionately identity documents: passports, national IDs, diplomas, caste and income certificates, minors' registration photos. Those are exactly the files you do not want in anyone's upload queue, retention log, or breach dump. Doing the compression locally removes the question instead of answering it with a privacy policy.

It also makes the service durable in the boring, practical sense: free and unlimited, no account, no watermark, no per-day cap, and the same experience on mobile and desktop. If your target is different, the slider covers 5 to 1000 KB, the related tools include a dedicated 20 KB preset and a size checker for measuring any image before or after compression, and none of them ask who you are.

Keep the compressed copy and the original separate from the start. Name the output with the target in the filename — passport-photo-100kb.jpg — so a month later you are not re-checking which file is which, and never overwrite the original with the compressed version. A folder per application, holding the source file and its compressed outputs, takes thirty seconds to set up and answers every 'which one did I upload?' question for good.

This also future-proofs you against the form changing its mind. Portals adjust their limits more often than they admit, and a 50 KB variant of an existing requirement is a five-second job when the original is one pass away — and a slow, quality-bleeding multi-pass job when it is not. One pass from the original to the final size, every time, and the 100 KB version stays as clean as the format allows.

For orientation before you start, here is how the common form limits compare and what a typical photo needs to do to fit each one. Your mileage shifts with content — busy backgrounds cost more than plain studio backdrops — but the table gives you the right neighborhood.