JPEG is the most-used image format on the internet, and also the most casually mishandled. Most people understand it as a single dial: drag "quality" up for a better-looking image, drag it down for a smaller file. That mental model isn't wrong, exactly — it's just missing about 70% of what actually determines a JPEG's final size and appearance.
This guide goes past the slider. We'll get into how JPEG actually transforms an image before a single bit gets written, why the "quality" number means something different in every encoder, why re-saving a JPEG is quietly destructive in a way PNG editing never is, the mistakes that cost photographers and developers real file size every day, and the expert-level techniques — chroma subsampling control, trellis quantization, progressive encoding, perceptual quantization tables — that separate a default export from a properly engineered JPEG. Whether you're a photographer prepping a portfolio, a developer optimizing a CDN pipeline, or an SEO professional chasing Core Web Vitals, this is the reference to keep open.
1. What JPEG actually is — and why "quality" is a lie
JPEG (Joint Photographic Experts Group) was standardized in 1992, built around a completely different premise than PNG. Where PNG guarantees pixel-perfect reconstruction, JPEG was designed from day one to throw information away — deliberately, selectively, and based on a model of what the human eye actually notices. That's not a flaw. It's the entire reason JPEG achieves compression ratios that lossless formats can't touch on photographic content.
But "throwing away information based on a model of human perception" means the quality slider you see in Photoshop, GIMP, or a browser-based compressor isn't a universal unit. It's an instruction to a specific encoder's specific implementation of that perceptual model. This is the first thing most guides get wrong by omission.
The quality number isn't standardized
There is no JPEG specification that defines what "quality 80" means in absolute terms. Quality is a 0–100 input to an encoder-specific formula that scales a base quantization table. Two different encoders — say, the classic libjpeg and the modern mozjpeg — can take the same source image, both export at "quality 80," and produce files of meaningfully different sizes and appearances. The number is a knob, not a measurement.
The structure of a JPEG file
Like PNG, a JPEG file is built from a sequence of markers — segments with a 2-byte identifier followed by segment-specific data. The ones that matter for compression and optimization:
- SOI / EOI — Start of Image and End of Image markers. Bookend the file. No size implications.
- APP0 (JFIF) / APP1 (EXIF) — Application segments. APP1 in particular is where camera metadata lives: make, model, exposure settings, GPS coordinates, lens data, and — critically — a thumbnail image embedded for preview purposes. This thumbnail alone is often 5–15 KB of dead weight for web use.
- DQT — Define Quantization Table. This is the heart of JPEG compression — the table of divisors that determines how aggressively each frequency component gets rounded. We'll unpack this fully in the next section.
- SOF — Start of Frame. Declares dimensions, bit depth, and crucially, the chroma subsampling mode and whether the file is baseline (sequential) or progressive.
- DHT — Define Huffman Table. The statistical encoding table used in the final compression stage. Default tables are "good enough"; optimized tables built specifically for the image's actual symbol frequencies save a further 2–6%.
- SOS / scan data — Start of Scan, followed by the actual entropy-coded image data. This is almost always the overwhelming majority of file size.
- ICC profile (APP2) — Embedded color profiles, often inserted by professional cameras and editing software at 0.5–3 KB. Necessary for color-critical print workflows; mostly unnecessary for sRGB web delivery.
Why "quality" is really three decisions, not one
A properly tuned JPEG export is actually the product of at least three semi-independent decisions, and most export dialogs collapse them into a single slider:
- Quantization aggressiveness — how much each 8×8 block of frequency data gets rounded. This is what the quality slider primarily controls.
- Chroma subsampling — how much color resolution is discarded relative to brightness resolution. Usually fixed by the encoder's default and rarely exposed to the user.
- Entropy coding strategy — baseline vs. progressive scan structure, and default vs. optimized Huffman tables. Almost never exposed in consumer tools at all.
Understanding that these are three separate levers — not one — is the difference between accepting whatever your export tool gives you and actually engineering the output.
2. How JPEG compression works under the hood
JPEG's compression pipeline has four distinct stages. Each stage throws away or restructures information in a specific, deliberate way. Understanding all four explains nearly every "why does this look like that" and "why is this file this size" question you'll ever have about a JPEG.
Stage 1: Color space conversion
Before anything else happens, RGB pixel data is converted to YCbCr — a color space that separates luminance (Y, brightness) from chrominance (Cb and Cr, the blue-difference and red-difference color channels). This single conversion is what makes the next stage possible. Human vision resolves brightness detail far more acutely than color detail — your eyes are much better rod-cell brightness detectors than cone-cell color detectors at fine spatial resolution. JPEG exploits this directly.
Stage 2: Chroma subsampling
Once the image is in YCbCr, the encoder can store the color channels (Cb, Cr) at lower resolution than the brightness channel (Y) with minimal perceptual impact. This is expressed in a three-number notation:
4:2:0 is the default in nearly every consumer camera, phone, and export tool, and for photographs it's nearly always the right call — it cuts the color data to a quarter of its original resolution while remaining visually transparent for natural imagery. The catch: 4:2:0 can visibly soften fine colored edges — thin red text on a white background, sharp color transitions in graphics, or saturated thin lines. This is precisely why JPEG is the wrong format for that kind of content, a theme we'll return to.
Stage 3: The Discrete Cosine Transform (DCT)
This is the conceptual core of JPEG. Each color channel is divided into 8×8 pixel blocks. Each block is then transformed — via the Discrete Cosine Transform — from a spatial representation (64 pixel intensity values) into a frequency representation (64 coefficients describing how much of each spatial frequency pattern, from "flat" to "rapidly oscillating," is present in that block).
The output isn't compressed yet — it's just reorganized. But that reorganization is what makes compression possible. Photographic content tends to be dominated by low-frequency information (smooth gradients, broad tonal areas) with comparatively little high-frequency content (fine, rapid detail). After the DCT, the top-left coefficient (the "DC" term) represents the block's average value, and the remaining 63 ("AC" terms) represent increasingly fine detail, ordered roughly from coarse to fine.
Stage 4: Quantization — where the actual loss happens
This is the only genuinely lossy step in the entire pipeline. Each of the 64 DCT coefficients is divided by a corresponding value from a quantization table, then rounded to the nearest integer. Because high-frequency coefficients are both perceptually less important and typically already small in magnitude, the quantization table divides them by much larger numbers — often rounding them straight to zero.
This is the actual mechanism behind the "quality" slider: a higher quality setting uses a quantization table with smaller divisors (less rounding, more coefficients survive); a lower quality setting uses larger divisors (more aggressive rounding, more coefficients become zero). Blocks full of zeros compress extremely well in the final stage — which is the entire point.
Stage 5: Entropy coding
After quantization, the now-mostly-zero coefficient blocks are reordered using a zigzag pattern (designed to group similar-magnitude low/high frequency coefficients together for better run-length behavior), run-length encoded, and finally Huffman coded — a statistical compression scheme nearly identical in spirit to the Huffman stage in PNG's DEFLATE pipeline. This stage is lossless: nothing is discarded here. All the actual visual loss already happened in quantization.
This matters because it means there's still a free lossless win available after quantization — exactly analogous to PNG's Zopfli recompression. Optimizing the Huffman tables for the specific symbol frequencies in a given image (instead of using the generic default tables), and switching to arithmetic or progressive encoding strategies, can shave additional size off the file without touching a single pixel value.
Why JPEG is generationally lossy — and PNG editing isn't
Here's the consequence that catches people out: every time a JPEG is decoded back to pixels, edited, and re-encoded, it goes through quantization again. The rounding errors from the first pass are baked into the pixel values; the second pass quantizes those already-corrupted values further. Repeat this enough times — open, crop slightly, save, open again, adjust levels, save again — and you accumulate visible "generation loss": blocky artifacts, color banding, smeared detail around edges. This has no equivalent in PNG editing, where every save is a fresh, exact lossless encode of whatever pixels currently exist. It's the single biggest structural difference between working with the two formats, and it's almost never explained clearly.
3. Quality settings vs. chroma subsampling: the real levers
If PNG's biggest hidden lever is color type, JPEG's is the combination of quality and chroma subsampling — and the interaction between them is far more consequential than tweaking either one in isolation.
Choosing a quality setting that actually means something
Quality is not linear, and the useful range is much narrower than the 0–100 scale suggests. In practice:
| Quality Range | Visual Result | File Size Behavior | Use Case |
|---|---|---|---|
| 95–100 | Visually indistinguishable from source | Disproportionately large — diminishing returns | Archival only |
| 85–92 | Excellent, artifacts essentially invisible | Moderate-large | High-end photography, hero images |
| 75–84 | Very good, no visible artifacts in normal viewing | Efficient — best size/quality ratio for most photos | General web use — recommended default |
| 60–74 | Good, minor artifacts visible on close inspection | Small | Thumbnails, bandwidth-constrained delivery |
| Below 50 | Visible blockiness, color banding, ringing near edges | Very small | Avoid except for tiny previews |
The single most useful number to remember: 95 → 85 typically cuts file size by 40–60% with a difference visible only in side-by-side pixel-peeping. 85 → 75 cuts another 20–30% and is still very hard to distinguish in normal viewing. 75 → 50 cuts size further but starts trading away real, visible quality. Diminishing returns set in fast above 85 and accelerate hard below 60.
Chroma subsampling: the lever almost nobody touches
Most JPEG export dialogs don't even expose chroma subsampling as an option — it's silently fixed to 4:2:0 regardless of quality setting. But for certain content types, this single setting matters more than 15 points of quality.
- Photographs of natural scenes (skin, landscapes, foliage) — 4:2:0 is correct almost always. The color information lost is below the threshold of perception for this content type.
- Product photography with sharp colored edges or labels — 4:2:2 or even 4:4:4 can be worth the file size cost if color fringing around text or edges is visible at 4:2:0.
- Screenshots, UI mockups, or graphics with colored text saved as JPEG — 4:4:4 is usually necessary, though honestly this content shouldn't be JPEG at all (more on that later).
- Images destined for further heavy editing — 4:4:4 preserves more color fidelity for downstream color grading work, reducing compounding loss from chroma information that can't be recovered.
Progressive vs. baseline encoding
Baseline JPEG stores image data top-to-bottom, in one pass — the image renders by drawing in complete from top to bottom as data arrives. Progressive JPEG stores the same information in multiple passes, each one refining the whole image's quality (first a blurry full-frame approximation, then progressively sharper full-frame refinements).
Progressive encoding's reputation is mostly about perceived loading behavior — a blurry-then-sharp full image feels faster than a sharp image drawing top-down, especially on slow connections. But progressive encoding also has a genuine, separate compression advantage: because coefficients are grouped and entropy-coded differently across scans, progressive JPEGs are typically 2–10% smaller than baseline JPEGs of the same visual quality, with the gain increasing on larger images. The tradeoff is slightly higher encoding and decoding CPU cost — generally a non-issue for web delivery, but occasionally relevant in CPU-constrained mobile decode scenarios or real-time pipelines.
4. The 9 most common JPEG compression mistakes
These patterns show up across professional portfolios, e-commerce catalogs, and CMS-driven blogs alike. Each one is silently costing file size, quality, or both.
Mistake 1: Treating quality 100 as "safe"
Quality 100 doesn't mean lossless — JPEG cannot produce a truly lossless output, ever, by design (chroma subsampling alone discards information before quantization even runs). What quality 100 actually does is use the smallest possible quantization divisors, which means almost no coefficients round to zero, which means the entropy coding stage has very little repetition to exploit. The result: files that are often 3–6× larger than quality 85 for a difference that's essentially invisible. If you need true lossless preservation, the answer is a lossless format — not a maxed-out lossy one.
Mistake 2: Repeatedly re-saving the same file
Covered above structurally, but worth stating as a habit to break: every open-edit-save cycle on a JPEG compounds quantization error. If you're doing iterative edits — cropping, color correction, retouching — work from a master file in a lossless or near-lossless intermediate format (TIFF, PSD, or even PNG for screenshots) and only export to JPEG as the final delivery step, once. Never use a JPEG as your working file during an editing session.
Mistake 3: Keeping the embedded EXIF thumbnail and full metadata
Camera-originated JPEGs carry an embedded EXIF thumbnail (a small preview image, often 160×120 or larger, fully re-encoded inside the file), plus potentially dozens of metadata fields: GPS coordinates, camera serial number, lens model, software version, copyright strings. None of it affects on-screen rendering. Combined, this routinely adds 10–60 KB to a file that didn't need any of it for web delivery.
Mistake 4: Ignoring chroma subsampling on the wrong content type
Saving a screenshot, infographic, or any image with crisp colored text or thin colored lines as a standard JPEG (4:2:0 default) produces visible color fringing and blur around exactly the content that needs to stay sharp. This isn't a quality-setting problem — cranking quality to 100 doesn't fix subsampling-related softness, because subsampling happens at a separate, earlier stage. The fix is either forcing 4:4:4 subsampling or, better, recognizing this content doesn't belong in JPEG at all.
Mistake 5: Exporting at full camera resolution for web display
A modern smartphone or DSLR produces images at 12–48 megapixels. A hero banner on a website rarely displays at more than 2–4 megapixels even on a high-DPI retina display. Compressing a 48-megapixel JPEG "well" and then scaling it down in an HTML <img> tag means the browser downloads 10–20× more pixel data than it ever renders. This single oversight dwarfs anything achievable through quality tuning — resizing to actual display dimensions before compression is consistently the highest-leverage optimization available, and it's the one most frequently skipped.
Mistake 6: Using one quality setting for every image on a site
A quality setting that looks great on a high-detail outdoor photograph can look noticeably worse on a smooth-gradient product shot or a portrait with large areas of soft, even skin tone — because smooth gradients reveal quantization banding more readily than busy, detailed textures do (busy detail visually masks artifacts; flat areas expose them). Applying a single global quality number across an entire image library is convenient but suboptimal. Per-image or per-category quality targets, validated visually, produce meaningfully better results for the same average file size.
Mistake 7: Not checking output at 100% zoom on detail-critical areas
Compression artifacts concentrate in specific places: fine hair detail, text overlays, sharp object edges against contrasting backgrounds, and smooth gradients (sky, skin, soft shadows). A thumbnail-sized preview in your export tool will almost never reveal banding or ringing artifacts that are obvious at full size. Always inspect detail-critical regions at 100% zoom before shipping a compressed file, especially below quality 80.
Mistake 8: Letting the encoder's default chroma and Huffman settings go unexamined
Most consumer-facing export tools hide subsampling mode and Huffman table strategy entirely, applying defaults silently. This isn't wrong for the majority of images, but for any high-traffic, high-value image (hero banners, product hero shots, og:image social previews), it's worth using a tool or encoder that exposes these settings — the gap between default libjpeg output and a properly tuned mozjpeg or jpegli export at equivalent visual quality is routinely 15–25%, for free, with no quality tradeoff at all.
Mistake 9: Treating "compress once" as a finished pipeline
Same root issue as in PNG workflows, but arguably worse for JPEG given generation loss: a CMS that accepts JPEG uploads from users or contributors without server-side reprocessing will accumulate camera-original files at full resolution with full metadata and unoptimized quality settings, indefinitely. Compression needs to be a pipeline stage that runs automatically on every new image, not a manual task performed occasionally on a handful of hero images.
5. Advanced tricks that most guides never mention
These go beyond "pick a quality number." They require understanding the pipeline stages well enough to intervene at the right point.
Trick 1: Trellis quantization
Standard JPEG quantization rounds each DCT coefficient independently to the nearest value, purely based on the quantization table — it has no awareness of how that rounding choice affects the entropy coding stage that follows. Trellis quantization (implemented in mozjpeg and a handful of other modern encoders) instead searches for the coefficient rounding decisions that minimize the actual final encoded bit cost, accounting for how Huffman coding will represent the result — essentially optimizing quantization and entropy coding jointly rather than sequentially.
The practical result: 5–15% smaller files at visually identical quality compared to standard quantization, with zero additional decode-side cost (any standard JPEG decoder reads the output fine — trellis quantization only changes how the encoder makes its rounding decisions, not the file format itself).
# mozjpeg's cjpeg enables trellis quantization by default
cjpeg -quality 82 -outfile output.jpg input.ppm
# Explicit control via jpegtran-style flags on some builds
cjpeg -quality 82 -optimize -progressive -outfile output.jpg input.ppm
Trick 2: Optimized Huffman tables instead of defaults
The JPEG spec includes a set of standard, generic Huffman tables that work reasonably well across "typical" images. But the actual symbol frequency distribution in any specific image is rarely identical to the generic assumption. Most encoders support an "optimize" flag that performs a second pass: analyze the actual quantized coefficient statistics for this specific image, then build custom Huffman tables tuned exactly to it.
This is a fully lossless optimization — pixel-equivalent output, smaller file, every time. The only cost is a second encoding pass, which is computationally trivial for anything except extremely high-volume batch pipelines.
# Re-optimize Huffman tables on an existing JPEG without re-quantizing
jpegtran -optimize -progressive -copy none -outfile output.jpg input.jpg
Notice this command operates on an already-encoded JPEG and never touches pixel data — it's purely a lossless structural re-optimization, directly analogous to running OxiPNG on an already-exported PNG. Running this on existing JPEG libraries can recover 3–8% with absolutely no quality risk.
Trick 3: Perceptually-tuned quantization tables (jpegli / mozjpeg)
The default JPEG quantization tables were derived from psychovisual research in the early 1990s, using the display and viewing conditions of that era. Modern encoders like Google's jpegli (part of the libjpeg-turbo ecosystem) and mozjpeg ship updated quantization tables informed by more recent perceptual research and tuned for modern display characteristics. Switching encoders alone — without changing the quality number you input — frequently yields visually equivalent output at 10–20% smaller size, simply because the underlying perceptual model is better calibrated.
This is the single highest-leverage "free" change available to anyone running a JPEG pipeline that still uses a default libjpeg or Photoshop export: swap the encoder, keep your quality workflow, get smaller files for the same visual result.
Trick 4: Selective region quality — don't compress everything equally
JPEG's 8×8 block structure means quantization aggressiveness is technically uniform across an image (within a single scan), but some advanced workflows work around this by compositing: compress a background region more aggressively (lower quality, since blur there is imperceptible) and a subject region — a face, a product, text — at higher quality, then composite the two before final encoding, or use encoder-level region-of-interest quality maps where supported. This is more involved than a single export setting, but for hero images where one specific region carries all the perceptual weight, it can produce significant size savings with zero quality cost where it matters.
Trick 5: Strip ICC profiles and convert to sRGB explicitly, rather than carrying both
Professional cameras and editing software frequently embed a full ICC color profile (Adobe RGB, ProPhoto RGB, or camera-specific profiles) rather than relying on the universally-supported sRGB default. For web delivery, where the overwhelming majority of displays and browsers assume sRGB, carrying a non-sRGB profile risks color-shifted rendering in any context that ignores the embedded profile, on top of the wasted bytes of the profile itself. The correct workflow: explicitly convert to sRGB during export (not just embed an sRGB tag on top of differently-profiled data), then strip the ICC profile entirely — browsers default to sRGB assumption anyway, so an explicit profile adds bytes without adding correctness once the conversion has actually happened.
Trick 6: Use arithmetic coding only when you control both ends — otherwise don't
The original JPEG spec includes an alternative to Huffman coding called arithmetic coding, which compresses slightly better (typically 5–7% smaller) but was historically encumbered by patents and is supported by far fewer decoders. For closed pipelines where you control both the encoder and every decoder (e.g., an internal image-processing service that never serves directly to arbitrary browsers), arithmetic coding is a legitimate small win. For anything served to the public web, stick to Huffman coding — browser support for arithmetic-coded JPEG is inconsistent enough to be a real compatibility risk, not a theoretical one.
Trick 7: Smart cropping before compression, not after
If an image will ultimately be displayed cropped — a square avatar pulled from a rectangular upload, a focal-point crop for a responsive hero — crop before compression, not after. Compressing the full original and then cropping in CSS or at render time means you paid the bandwidth cost for pixel data that's discarded the moment it hits the browser. Crop first, then compress only the pixels that will actually be seen.
6. When to stop using JPEG entirely
Just as the best PNG optimization is often "don't use PNG for this," the best JPEG optimization is sometimes recognizing JPEG is the wrong format for the content in front of you.
Use WebP or AVIF instead for almost everything new
For photographic content where browser support permits, modern formats beat JPEG outright. WebP lossy typically produces files 25–35% smaller than JPEG at equivalent visual quality. AVIF goes further — commonly 30–50% smaller than JPEG at equivalent quality, owing to a more modern transform and better entropy coding, though at a meaningfully higher encoding time cost. Both have near-universal browser support as of 2026. The honest case for sticking with JPEG in a greenfield project is shrinking every year — mostly compatibility with older tooling, certain print/export pipelines, and ecosystems (some email clients, some legacy CMS platforms) that still expect it specifically.
Use PNG instead for anything with hard edges, text, or flat color
This is the mirror image of the PNG guide's "don't use PNG for photos" advice. If your image is a screenshot, a UI mockup, a chart, an infographic, or anything containing crisp text or sharp geometric edges, JPEG's DCT-and-quantization approach actively fights against that content. Smooth photographic gradients hide the blocky 8×8 artifacts of quantization; flat color fields and hard edges expose them mercilessly, with visible ringing artifacts ("haloing") around sharp transitions. The fix isn't a higher quality setting — it's switching to a format whose compression model matches the content. PNG (specifically indexed-color PNG for low color counts) handles this kind of image far better, often at a smaller file size than even a high-quality JPEG of the same content.
Use SVG instead for logos and icons
If you've ever seen a logo saved as a JPEG, you've probably also seen the faint colored fringing around its edges and the slightly muddy flat-color fills — both classic symptoms of quantization and chroma subsampling fighting against vector-style content. Logos, icons, and any graphic composed of clean geometric shapes belong in SVG: infinitely scalable, typically smaller than even a well-optimized JPEG of the same graphic, and rendered pixel-perfect at any size.
Use GIF or video for animation — never JPEG
JPEG has no animation support at all (Motion JPEG exists but is a video container convention, not something browsers render as an image tag). If you're working with animated content, that's a GIF, APNG, animated WebP, or — for anything longer or more complex than a short loop — an actual muted MP4 video element, which will almost always outperform any image-based animation format on file size.
7. Building a real compression workflow
A single well-compressed hero image is a nice win. A pipeline that guarantees every image — uploaded by anyone, at any time, in any state — gets processed correctly is the difference between a fast site and a site that slowly bloats with every CMS update and user upload.
The decision gate before any JPEG is touched
- Does this image contain text, flat color, or sharp geometric edges? → It probably shouldn't be a JPEG at all. Route to PNG (indexed) or SVG.
- Is this a genuine photograph with no transparency need? → JPEG is appropriate, but evaluate WebP/AVIF first if browser support allows.
- Does the destination context require universal legacy compatibility? → JPEG, with a modern encoder (mozjpeg/jpegli), quality 75–85, progressive, optimized Huffman, stripped metadata.
- Will this image undergo further edits later? → Keep a lossless master (TIFF, PSD, or even PNG); export JPEG only as the final delivery artifact, once.
- Does fine colored detail matter (sharp colored text, thin saturated lines)? → Consider 4:4:4 or 4:2:2 subsampling instead of default 4:2:0, or reconsider whether JPEG is the right format at all.
Sizing before compression — always first
Exactly as with PNG: compress the image at the resolution it will actually be displayed at, not at upload resolution. Generate the sizes you actually need and serve them responsively:
<img
src="product-800.jpg"
srcset="product-400.jpg 400w, product-800.jpg 800w, product-1600.jpg 1600w"
sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1600px"
alt="Product photo"
width="1600"
height="1067"
loading="lazy"
>
Integrating compression into CI/CD
In Node-based pipelines, Sharp (wrapping libvips, which itself can use mozjpeg under the hood) handles resize, format conversion, and quality control in one pass. In Python pipelines, Pillow combined with a mozjpeg or jpegli binary via subprocess gives full control over quality, subsampling, and progressive encoding independently. In containerized batch pipelines, ImageMagick or direct cjpeg/jpegtran invocations script cleanly and are easy to parallelize across large image libraries.
The principle is identical to PNG: no image should reach production in its original upload state. Every JPEG should pass through resize, format-appropriateness check, metadata stripping, and quality/subsampling tuning as a mandatory pipeline stage — not a manual afterthought applied to a handful of hero images while everything else slips through unprocessed.
Auditing an existing image library
Before building a forward-looking pipeline, find out what you're already carrying. Lighthouse, browser DevTools' network panel sorted by transfer size, and batch tools that report quality/subsampling/dimension metadata across a directory will quickly surface which images are the worst offenders. As with PNG, prioritize by potential savings multiplied by traffic — a 2 MB product hero JPEG on a high-traffic landing page deserves attention long before a 150 KB blog thumbnail that gets a handful of views a month.
Setting file size targets by category
| Image Category | Target Max Size | Suggested Quality / Subsampling |
|---|---|---|
| Hero / above-the-fold photo | 100–180 KB | Q80–85, 4:2:0, progressive |
| Product photo (e-commerce grid) | 30–60 KB | Q75–80, 4:2:0 |
| Blog / article inline photo | 60–120 KB | Q75–82, 4:2:0, progressive |
| Thumbnail / grid preview | 8–20 KB | Q65–75, 4:2:0 |
| Social share image (og:image) | 50–100 KB | Q80, 4:2:0, baseline (some platforms re-encode anyway) |
| Print-ready / archival master | N/A — use TIFF/PSD instead | Avoid JPEG for this role entirely |
Same rule as with PNG: when an image blows past its budget, the right response is diagnosis, not brute-force recompression. Is it at the wrong resolution for its display context? Carrying unnecessary metadata? Using 4:4:4 subsampling on content that doesn't need it? Identify the actual cause before reaching for the quality slider again.
8. Frequently asked questions
What is the best JPEG quality setting for web images?
Quality 75–85 with a modern encoder (mozjpeg or jpegli rather than a default libjpeg export) gives the best balance of file size and visual quality for the overwhelming majority of photographic web images. Below roughly 70, artifacts start becoming noticeable in detailed or gradient-heavy areas; above 90, file size grows quickly for almost no visible quality improvement. Always verify visually for your specific image rather than treating any single number as universal.
Does saving a JPEG multiple times reduce quality?
Yes, and this is one of the most important structural facts about the format. Every decode-edit-re-encode cycle runs the quantization step again on data that's already been rounded once. Even re-saving without any edits, at the same quality setting, can introduce additional loss in most standard editing tools, because the file is fully decoded to pixels and fully re-quantized rather than having its existing compressed data preserved. Work from a lossless master file during editing and export to JPEG only as a final, single step.
What is chroma subsampling and does it matter?
Chroma subsampling reduces color resolution while preserving full brightness resolution, exploiting the fact that human vision resolves luminance detail far more acutely than color detail. The default mode, 4:2:0, reduces color data to a quarter of full resolution and is typically imperceptible on photographs, saving roughly 15–30% in file size versus no subsampling. It does become visible — as softened or fringed edges — on content with fine colored text or thin saturated lines, which is a strong signal that content shouldn't be a JPEG in the first place.
Should I use JPEG or WebP/AVIF for web images?
For photographic content, both WebP and AVIF generally beat JPEG on file size at equivalent visual quality — WebP by roughly 25–35%, AVIF often by 30–50%, though AVIF encoding is noticeably slower. JPEG remains relevant where universal compatibility without fallback logic matters, in some legacy tooling and email-client contexts, and where extremely fast, low-overhead encoding at scale is a priority. For most new web projects in 2026, serving WebP or AVIF with a JPEG fallback is the stronger default.
Why does my "compressed" JPEG sometimes come out larger?
This usually traces to one of a few causes: the new export used a higher quality setting or less efficient chroma subsampling (4:4:4 instead of an original 4:2:0) than the source file; the tool re-added a large ICC profile or didn't strip embedded EXIF data and thumbnails that a previous export had already removed; or the source was already heavily compressed and the new pass, using a less optimized encoder or default Huffman tables, simply produced a less efficient result on the same visual target. Compare quality settings, subsampling mode, and metadata presence between input and output to diagnose it.
Can I convert a JPEG to PNG to "preserve" its quality?
No — and this is a common, well-intentioned mistake. Once a JPEG has been quantized, the information loss has already happened and is baked into the pixel values. Converting to PNG afterward locks in those lossy pixel values losslessly going forward (no further quality loss from that point on), but it does not recover any of the original detail, and it will typically produce a much larger file than the JPEG for no quality benefit whatsoever. The fix is to go back to an earlier, less-compressed source if one exists — conversion after the fact can't undo quantization.
Is progressive JPEG always the right choice?
For typical web delivery, yes — progressive JPEGs are usually both smaller and perceived as loading faster than baseline JPEGs of the same image. The exceptions are scenarios with tight CPU constraints on the decode side (some older or very low-power embedded devices decode progressive JPEGs more slowly) or pipelines that specifically require baseline output for compatibility with a downstream tool that doesn't handle progressive scans correctly. For the vast majority of modern web and app delivery, progressive is the better default.