Image Size Checker — Check Any Image Size in KB

The single most common misunderstanding about images is that dimensions and file size are the same thing. They are not. Pixel dimensions describe how many tiny squares of color make up the picture — a 4000×3000 image has 12 million of them. File size in KB describes how many bytes it takes to store that picture on disk. The two are related, but the relationship depends on what is in the photo and how it was saved.

This matters because upload forms check different things. Some validate pixel dimensions ("minimum 600×600 px"), some validate file size ("maximum 100 KB"), and some check both independently. A photo can pass one check and fail the other in the same breath. A 300 KB image at 6000×4000 pixels passes the size limit and blows the dimension cap; the same frame re-saved at 800×600 might land at 40 KB and pass everything.

The checker above shows you both numbers at once, so you never have to guess which requirement your file is about to trip. Check the KB figure against the size limit, check the pixel figure against the dimension limit, and only then attempt the upload. It takes five seconds and removes the most common round of form rejection entirely.

Two photos from the same phone, both 12 megapixels, can differ in file size by a factor of fifteen or more. The explanation is compression efficiency: JPEG stores not the pixels themselves but a description of how they change. Smooth areas — sky, walls, blurred backgrounds, studio backdrops — need almost no description and cost almost no bytes. A 12 MP portrait against a clean backdrop can genuinely compress to 300–500 KB.

Busy content is the opposite. Foliage, grass, crowds, gravel, textured fabric, and heavy film grain contain detail at every scale, and the encoder must spend bits describing all of it. Point the same 12 MP camera at a forest or a stadium crowd and the file lands at 4–6 MB without any change in settings. The subject, not the sensor, sets the size.

This is why comparing your file to someone else's is pointless, and why measuring your own is the only reliable move. The rule of thumb for planning: if your original is under 1 MB, it probably contains little fine detail and compresses easily; if it starts at 5 MB or more, expect to either trim dimensions or accept a visible quality trade to hit a tight limit. Drop it in the checker first and you will know which situation you are in.

Format choice moves the numbers more than any quality slider. As a rough guide for a 12 MP photograph: a PNG of that photo weighs 8–15 MB, because PNG is lossless and was designed for graphics, not photos. A JPEG of the same frame weighs roughly 2–5 MB at full quality — the format's classic 10:1 compression ratio over raw data — and a few hundred KB once tuned. WebP typically lands 25–35% smaller than the equivalent JPEG; AVIF goes further, commonly around 50% smaller than JPEG at comparable visual quality.

HEIC, the default on iPhones since iOS 11, performs similarly to WebP — a straight-from-the-camera HEIC photo is usually 1–2 MB. GIF sits at the bottom of the scale for photos: limited to 256 colors, it produces either tiny, ugly photos or enormous files, and it belongs in animations only. Screenshots and flat graphics flip the ranking — PNG frequently beats JPEG there, because sharp edges and flat fills are exactly what PNG encodes cheaply and JPEG smears with artifacts.

The checker reads the format alongside the size for exactly this reason. If a file is mysteriously heavy, the first thing to ask is not "how much quality can I sacrifice" but "is this even the right format." A 6 MB PNG that is really a photograph becomes a 400 KB JPEG with no visible difference and no dimension change at all — the single largest win available, and it costs nothing.

The 100 KB cap on a government form is not arbitrary and it is not hostile — it is a storage and bandwidth budget. If a portal collects 100,000 applications a year and each photo weighs 5 MB instead of 100 KB, the difference is roughly 490 GB of extra storage, multiplied by every backup copy, plus the CDN egress traffic every time an officer opens the file. At cloud pricing, small caps save real money at scale.

There is a user-side reason too. Admission and exam portals serve millions of applicants, many on slow mobile connections in areas with weak coverage. Pages that load ten 5 MB images take minutes and fail outright on metered or 2G-class connections; pages serving 100 KB thumbnails load in a blink everywhere. The low cap keeps the whole system responsive for the people who use it under the worst conditions.

Understanding the budget helps you hit it intelligently. The form does not need your photo's full resolution — it needs a recognizable, legible image that fits its pipeline. That is a solvable engineering problem, not a fight: measure the file, see how far it is from the cap, and reduce dimensions or quality until it fits. Most form photos look perfectly fine at a size that satisfies even a 20 KB limit.

Some systems do not store images as separate files at all — they embed the image directly into text: HTML pages, CSS stylesheets, JSON API payloads, and, importantly, email. The scheme is called Base64, and it rewrites the raw binary bytes using only 64 text-safe characters. Because every 3 bytes of binary becomes 4 characters of text, the result is always about 33% larger than the original file — often 33–37% once padding and line breaks are counted.

This shows up in places you would not expect. Attach a 3 MB photo to an email and the message grows by roughly a megabyte before it is sent, because mail transport encodes attachments in Base64. A developer inlining a logo into a web page ships 33% more bytes than the file itself weighed. Some upload systems that store images inside database rows or JSON records pay the same overhead permanently.

The practical takeaway: when a system says "25 MB total," treat your effective budget as about 18 MB of actual files, because transit encoding will add its third before delivery. And when you measure an image before inlining or attaching it, measure knowing the final footprint will be a third larger than what the checker reports.

A photo file is not just pixels. Cameras embed a metadata block — EXIF, the Exchangeable Image File Format standard — recording the timestamp, camera model, lens, exposure settings, orientation, and, if location services were on, GPS coordinates accurate to a few meters. A second embedded thumbnail, color profiles, and editing-history tags from apps like Lightroom or Snapseed frequently ride along.

All of that costs bytes: typically 5–100 KB per photo, depending on the camera and how many apps have touched the file. On a 5 MB original it is noise. On a form that demands a file under 100 KB, metadata alone can consume half your budget — or tip an otherwise-compliant photo over the line. GPS data in particular is worth stripping before uploading identity documents anywhere, both for size and because a photograph that quietly contains your home coordinates is a privacy leak on its own.

Re-encoding an image — which is what every compressor on this site does — rebuilds the file from the decoded pixels and leaves EXIF behind by default. The output is smaller by the metadata's weight and cleaner by the same amount. Check the original first to see how much of its size is picture versus paperwork; heavy-EXIF files are the pleasant surprises of compression.

Email remains where size limits bite most people first. Gmail caps the total size of a message — attachments included — at 25 MB, Outlook sits at 20 MB for most accounts, and many corporate and university servers enforce older, lower limits of their own. Hit the cap and the message either bounces back or the provider silently offers to convert it into a cloud link, which is small comfort if your recipient needed an actual file.

The wall arrives faster than the numbers suggest, for the Base64 reason above: attachments are re-encoded for transit at roughly 4/3 their original size. Three 8 MB photos from a modern phone already total 24 MB on disk and over 30 MB encoded — bounced before you typed a word. Meanwhile five photos compressed to 150 KB each make a sub-1 MB message that clears any mail server on the planet.

The workflow is simple: measure each photo in the checker, decide how much of the 25 MB budget it deserves, and compress the ones that do not fit. For photo-heavy mail to family, 200–500 KB per image is visually indistinguishable from the original at normal viewing sizes. For documents, most scans email cleanly at under 500 KB per page.

Since iOS 11, iPhones save photos in HEIC by default — a format with compression efficiency well ahead of JPEG, typically producing files around half the size of an equivalent-quality JPEG. A straight-from-camera HEIC snapshot weighs 1–2 MB and looks superb. The catch arrives the moment a form, a Windows machine from before Windows 10 (1809), or an older Android app demands a JPG.

Exporting that HEIC to JPEG — whether through the Photos app's "Most Compatible" setting, AirDrop conversion, or a converter site — re-encodes the same pixels into the older, less efficient format, and the file commonly doubles. A 1.5 MB HEIC becomes a 3 MB JPG. Nothing about the image changed; only the container did. Users who toggle "Most Compatible" permanently pay this tax on every photo they ever take.

So if your upload limit is tight and your source is an iPhone, do not stop at format conversion — you would be uploading a file twice the necessary size. Convert or compress in one step instead, targeting the KB limit directly. The pixels that matter survive fine; the format inefficiency does not need to come along for the ride.

Multi-page uploads are where size discipline pays off most. Application portals frequently accept a combined PDF or a set of scans under one total cap — say 1 MB for the lot. Divide the cap by the number of pages and you get a per-page budget: four pages under a 1 MB ceiling is roughly 200–250 KB each. Exceed it on one page and the whole submission bounces.

Scans vary wildly within the same document. A page of dense handwriting or a stamped certificate at 300 DPI can weigh 1 MB or more in PNG, while the near-blank inside cover of the same booklet weighs 40 KB. Scanner defaults are rarely tuned for upload caps; they are tuned for print quality. Left alone, a five-page scan job at default settings routinely produces 5–10 MB.

The working method: scan everything first, then weigh each page in the checker, then compress from heaviest to lightest until the total fits the budget. Compressing the 1 MB handwriting page buys you more headroom than fixing ten blank pages ever will. If the portal accepts PDF, note that many forms also enforce a per-page minimum legibility — so keep the text page readable and spend your savings on the pages that need it.

You will notice that different tools report slightly different sizes for the same file, and the gap is not an error. Strictly defined, a kilobyte is 1,000 bytes and a kibibyte (KiB) is 1,024 bytes — the binary unit. Operating systems have historically blurred the two: macOS reports file sizes in decimal units (divide by 1,000), while much Windows tooling and older conventions divide by 1,024 and label the result KB anyway.

The effect compounds at larger sizes. A file of exactly 1,000,000 bytes is 1.000 MB decimal but 0.954 "MB" binary; a "5 MB" photo on disk may be reported anywhere from 4.77 to 5.00 MB depending on the tool. For a form limit, the discrepancy is about 2.4% per step — small, but enough to matter when your file sits within a few percent of the cap, which is precisely when it matters most.

This is one more argument for measuring rather than trusting labels. Our checker reports the raw byte count alongside the kilobyte figure, so you can compare against any limit the form states and keep a margin if you are unsure which convention the portal uses. A file compressed to 95 KB will pass a 100 KB limit under either definition; one at 99.5 KB may not.

The floor on any image's file size comes from how pixels are stored. The standard is 8 bits per channel — 256 levels per color channel. An RGB image has three channels, so every pixel costs 3 bytes; add a transparency channel and it is 4. A 12 MP RGB image therefore represents 36 MB of raw pixel data before any compression, and a 48 MP one represents 144 MB.

Compression exists to close that gap, and the formats differ in how far they can go. JPEG typically achieves around 10:1 on photographic content with little visible loss — turning that 36 MB of pixels into a few MB on disk — and far more on smooth subjects. PNG records the pixels losslessly, so its size floats just under the raw figure for photographs. AVIF and WebP use smarter prediction of neighboring blocks and can cut another 30–50% from the JPEG result.

Higher bit depths multiply everything. A 16-bit-per-channel scan costs twice the raw bytes of an 8-bit one, and professional RAW formats store sensor data before any of the camera's compression decisions. That is why a "photo" can weigh 75 MB before you ever see it as a JPEG — the next section covers exactly that case.

At the far end of the scale sits the modern pro-mode photograph. An iPhone 14 Pro or later shooting 48 MP Apple ProRAW produces a file around 75 MB — roughly ten to thirty times a normal JPEG from the same camera. The reason is that ProRAW is not a finished picture: it stores the raw sensor readings with per-pixel depth and the camera's own processing pipeline attached, leaving every adjustment decision to you.

Other systems are comparable. A full-frame mirrorless camera's uncompressed RAW files run 45–90 MB; compressed RAW lands around 25–45 MB. These files are wonderful editing sources and terrible upload candidates. No form on Earth accepts a 75 MB photo, and no recipient wants one by email — the format is a negative, not a print.

The path from there to any form limit is the same two-step as everything on this page: measure first, then compress from the original in one pass. Export the RAW to JPEG or let the compressor handle it, and a 75 MB negative becomes a 150 KB upload that still carries all the sharpness the form's display size can show. The checker is how you confirm you actually landed where you aimed — and with files this heavy, one wasted upload attempt costs real minutes.

Open the same file on three different devices and you will often see three different size readings. This is not a bug — it is a consequence of how each platform counts and displays bytes. macOS Finder, since OS X Lion, reports file sizes in decimal: one kilobyte is exactly 1,000 bytes, and one megabyte is exactly 1,000,000 bytes. A photo that Windows Explorer reports as 3.81 MB will appear as 4.00 MB in Finder — the raw byte count divided by different denominators.

Windows historically used binary units (1 KB = 1,024 bytes, 1 MB = 1,048,576 bytes) while labeling them with the SI symbols KB and MB rather than the technically correct KiB and MiB. Modern Windows 11 still defaults to this convention in Explorer. The mismatch between platforms is about 5% per step in the prefix chain — small on a 5 MB photo, but significant if your budget is 100 KB and your margin is thin.

The iPhone adds a third complication: iOS compresses photos in HEIC and reports the resulting file size in decimal, but the Photos app also shows the resolution and a 'modified' size if the image has been edited — and that figure reflects the edit buffer, not the export file. When you need to know the precise byte count that a server will receive, the only reliable method is to export or download the file and measure it with a tool that reads the filesystem byte count directly. The checker on this page does exactly that — it reads the raw byte count from the browser's File API, the same number the upload form will compare against its limit.

Knowing the KB figure is most useful when you have a target in mind. Common real-world ceilings cluster around a handful of values, and matching your file to the right one is faster when you know the context behind each limit. Email attachments: Gmail enforces a 25 MB message cap and Outlook one of 20 MB, but because attachments are Base64-encoded in transit, the effective file budget is closer to 18 MB and 15 MB respectively. If you are sending several photos, the combined encoded size is what counts — measure each one, sum them, and add a third.

Government and exam portal uploads almost universally demand files under 200 KB to 2 MB per document. Passport and visa photo portals are stricter: the UK HMPO, for instance, specifies 50 KB to 10 MB but other portals cap at 20 KB. E-commerce product images follow a different logic: Shopify recommends staying under 20 MB per image for upload, but the practical target for page-speed is far lower — a main product image above 200 KB will drag Core Web Vitals scores, because the Largest Contentful Paint element is almost always a hero image.

For web performance specifically, Google's guidance on LCP images suggests aiming for a total page weight where the LCP resource loads in under 2.5 seconds on a mid-range mobile connection. On a 4G link averaging 20 Mbps, a 200 KB image transfers in roughly 80 ms; a 2 MB one takes 800 ms and can single-handedly push LCP past the threshold. Measuring the file before and after compression with the checker lets you verify that a compression step actually moved the number — sometimes a 'compressed' export from editing software re-encodes to a larger size if the quality setting was raised.

When an upload form says '5 MB maximum', it does not specify which megabyte it means — and the answer determines whether a 4,900,000-byte file passes or fails. In practice, most web forms written in the past decade use the JavaScript File API, which exposes a size property in bytes. The developer then compares that number against a threshold they typed into the code. If they typed 5 * 1024 * 1024, the limit is 5 MiB (5,242,880 bytes); if they typed 5 * 1000 * 1000, it is 5 MB (5,000,000 bytes). There is no way to know which from the label alone.

The 4.7% gap between 5 MB and 5 MiB is small in absolute terms but predictable in how it bites. Files that sit between the two values — between 5,000,001 bytes and 5,242,880 bytes — pass a decimal check and fail a binary one. If your file is hovering just under a stated limit and still getting rejected, this is the first thing to investigate. Compress to 95% of the stated limit and the ambiguity disappears regardless of which convention the form uses.

The same ambiguity applies to storage displays elsewhere. An operating system that shows '4.65 GB' for a file is giving you the binary reading; a drive manufacturer advertising '500 GB' is counting decimal. Cloud storage quotas — Google Drive, iCloud, Dropbox — all use decimal gigabytes for their displayed numbers and their enforcement logic. So when Google says you have 15 GB free and your photo library shows 14.8 GB, it is comparing decimal gigabytes on both sides consistently. The confusion mostly arises at the cross-boundary between OS tools (binary) and web services (decimal). Knowing which side of that boundary your upload form sits on — and leaving a comfortable margin — removes the last source of size-related surprises.

On Windows, right-click the image file and choose Properties. The General tab shows two figures: Size (the raw byte count expressed in KB or MB) and Size on disk (rounded up to the filesystem cluster boundary, typically a few KB larger). The Details tab adds the pixel width, height, and resolution in DPI. One caveat: Windows Explorer uses binary KB — 1 KB equals 1,024 bytes — so the number it displays will be slightly smaller than the decimal KB figure that most web upload forms compute using the JavaScript File API. If you are right on a limit, measure with the checker above to get the exact byte count and avoid the ambiguity.

On macOS, select the file and press Command-I, or right-click and choose Get Info. The Size line shows both the human-readable figure and the raw byte count in parentheses: for example, '4.2 MB (4,194,032 bytes)'. The parenthetical byte count is exact and safe to compare against any form limit regardless of unit convention. For a faster read, press the Space bar to open Quick Look — the preview header shows the pixel dimensions and file size without opening a separate window. To sort a folder by size, switch Finder to list view and click the Size column header.

On iPhone, open any photo in the Photos app and tap the info button (the circled i at the bottom). The panel shows the file size in MB alongside the pixel dimensions, format, and camera data. If you need the number in KB, save the photo to the Files app, long-press the file, and tap Info — that screen gives the size to the nearest kilobyte. On Android, most gallery apps expose a Details or Info option from the three-dot menu, showing size in KB or MB. The Google Files app lists sizes in its browse view and lets you sort by size to find the largest images in a folder. For any platform, the checker on this page gives a more precise reading than any system file manager, and it works without navigating out of your browser.

Once the checker shows you the file's KB count, the compression strategy depends on how far you are from the target. A file that is 10 to 20 percent over the limit usually needs only a quality reduction — dimensions stay the same and the result is visually identical at screen sizes. A file that is two to ten times over the limit needs both a dimension reduction and a quality pass, because quality alone rarely achieves compression ratios beyond 3:1 without introducing visible banding or smearing.

As rough starting points: for a 50 KB target, most photos fit when resized to around 800 by 600 pixels with a moderate quality setting. For a 100 KB target, 1200 by 900 pixels at medium-high quality usually clears it. For a 200 KB target, most phone photos reach it at around 1600 by 1200 pixels with a small quality reduction. These are estimates — subject matter affects the result significantly, which is why the measure-then-compress cycle matters. Check the original, compress, then drop the result back into the checker to confirm before committing to the upload.

The specific compressor pages linked in the Related tools section below are prebuilt for the most common limits. The 50 KB tool is tuned for government ID photo and visa application portals that enforce strict caps. The 100 KB compressor covers the most common passport photo and academic profile portals. The compress-to-KB tool lets you enter any custom target in KB and adjusts quality and dimensions automatically. All of them process files locally in the browser, so the workflow is: check KB here, compress there, check KB again to confirm, then upload.

Upload limits cluster around a handful of common values, each reflecting a different infrastructure context. Knowing which tier you are in tells you immediately how hard the compression task is and which tool to reach for. The table below summarizes the four most common thresholds, their typical contexts, and the dimension range that usually fits within budget.

The 20 KB tier is the most demanding and is mostly found on older government portals and signature-image fields. At this size, pixel dimensions must be small enough that JPEG has almost nothing to encode: a 200 × 200 or 150 × 150 image with a plain background can clear it, while a detailed portrait typically cannot. If your form asks for a signature or a small thumbnail rather than a face photo, you are in this tier.

The 50 KB and 100 KB tiers are where most passport, visa, and academic portal requirements land. A 50 KB resize typically needs a dimension cut to around 600 × 800 and a moderate quality reduction; a 100 KB target is more forgiving and often reachable with dimensions alone. For any custom KB target, the compress-to-KB tool lets you dial in the exact number.