Compress JPG Online — Reduce JPEG Size via Quality Re-encoding

Q: Can I compress the same JPG twice?

You can, but every pass adds artefacts. JPEG is lossy by design (ITU-T T.81 / ISO/IEC 10918-1, 18 September 1992) — quality 1–100 maps to quantisation table scaling per Annex K. Each re-encoding multiplies the existing 8×8 DCT coefficients by a finer quantisation table and rounds to integer values, so block boundaries sharpen, ringing accumulates near edges, and gradients band progressively. Always compress from the original master rather than chaining compression passes; if the master is already a JPEG, compressing it once at quality 80 typically produces invisible loss while compressing the same JPEG twice at quality 80 visibly degrades.

Q: Does this tool resize my image?

No. Compression only re-encodes the existing pixels — dimensions stay exactly the same. The quality slider controls JPEG quantisation table scaling per ITU-T T.81 Annex K, which affects how aggressively DCT coefficients are rounded but not the image dimensions. For smaller dimensions, use the bulk-resize or resize-image tool first, then run the resized output through the compressor. browser-image-compression (npm v2.0.0+, Donaldcwl) has a maxWidthOrHeight option that combines resize + compress, but this dedicated compress-jpg tool keeps the steps separate for clarity.

Q: Will my photo's EXIF metadata survive compression?

By default no — Canvas-based re-encoding via toBlob('image/jpeg', quality) strips the JPEG APP1 marker carrying EXIF (JEITA CP-3451X / CIPA DC-X008-2019, Exif Version 2.32, revised 17 May 2019). This is the privacy-default behaviour: GPS coordinates, camera serial, timestamps, and lens identifiers don't follow into the compressed output. browser-image-compression has an opt-in preserveExif option that retains the APP1 marker if you specifically need EXIF round-trip. JFIF v1.02 APP0 marker (Hamilton, C-Cube Microsystems, 1 September 1992) is preserved as part of the standard JPEG container.

Q: Is my photo uploaded to a server?

No. Compression runs on the Canvas in your browser locally — verifiable in DevTools Network tab where no upload requests fire. The pipeline is decode-original-JPEG-to-pixels → drawImage to Canvas → toBlob('image/jpeg', quality) which encodes via the browser's built-in JPEG encoder. browser-image-compression library (used here) optionally moves the work to a Web Worker via OffscreenCanvas, keeping the main thread responsive for batch processing. No file leaves your device, no copies are stored, no telemetry is recorded.

JPG Compressor — DCT Quantisation per ITU-T T.81 Annex K

JPEG (ITU-T T.81 approved 18 September 1992 / ISO/IEC 10918-1:1994) uses lossy DCT + Huffman quantisation tuned for photographic content — it discards visual information your eye is least likely to miss, trading perfect fidelity for substantial file-size reduction. The quality slider (1–100) maps directly to Annex K quantisation table scaling: higher quality = smaller quantisation steps = more DCT coefficients preserved = larger file. Quality 90+ keeps photos visually identical to lossless; 75–85 is the web sweet spot per industry consensus; below 60 compression artefacts (8×8 block boundaries, ringing, banding) become noticeable on gradients and skies. The output is a standard JPEG wrapped in JFIF v1.02 (Eric Hamilton, C-Cube Microsystems, 1 September 1992) that opens everywhere. Note: re-compressing an already-compressed JPG always introduces additional generation loss — quantisation rounding accumulates with every pass.

How to compress a JPG

Drop a .jpg / .jpeg file onto the tool or click to browse — single file or batch.
Drag the quality slider down. 80–85 is the web sweet spot for photos; 70 is aggressive but often acceptable.
Watch the savings percentage. If 8×8 block boundaries or ringing become visible, raise the quality.
Download the compressed copy. Keep the original master if you may need to re-export later (re-compression compounds loss).

Common use cases

Optimising e-commerce product photos so pages load faster — JPG quality 85 typical, no visible loss to shoppers.
Squeezing travel photos under email attachment limits (10 MB Gmail / 25 MB Outlook) without resizing.
Cutting blog post image weight for better Core Web Vitals (Largest Contentful Paint) — quality 80–85 typical.
Trimming phone photos before cloud backup (Google Photos, iCloud, Dropbox) — typical 40–70% storage reduction.

Frequently asked questions

Can I compress the same JPG twice?

You can, but every pass adds artefacts. JPEG (ITU-T T.81, 1992) is lossy by design — quantisation rounding compounds with each re-encoding. Always compress from the original master rather than chaining passes.

What quality is the right default for web?

75–85 is the standard web sweet spot per industry consensus. Quality 85 = 40–70% size reduction with artefacts most viewers won't notice. Quality 70 = aggressive for image-heavy pages where total weight matters more than fidelity.

Does this tool resize my image?

No. Compression only re-encodes pixels — dimensions stay the same. The quality slider controls T.81 Annex K Q-table scaling. For smaller dimensions, use bulk-resize or resize-image first.

Will my photo's EXIF metadata survive compression?

By default no — Canvas re-encoding strips JPEG APP1 EXIF (JEITA CP-3451X / CIPA DC-X008-2019, Exif 2.32, May 2019). Privacy default. browser-image-compression has opt-in preserveExif flag.

Is my photo uploaded to a server?

No. Compression runs locally on the Canvas in your browser — verifiable in DevTools Network tab (no upload requests fire). Optional Web Worker via OffscreenCanvas keeps main thread responsive for batch processing.

Why JPEG re-encoding always costs quality — and how to minimise the cost

JPEG quantisation is fundamentally non-reversible. The encoder takes 8×8 pixel blocks, applies a Discrete Cosine Transform to convert spatial pixel values into frequency coefficients, then divides each coefficient by a quantisation table value and rounds to the nearest integer. The rounding is where information is permanently discarded. When you re-encode a JPEG: the decoder reconstructs approximate pixel values from the previously quantised coefficients (introducing decoding error), then the encoder applies a (potentially different) quantisation table and rounds again (introducing additional encoding error). Compounding effects: 8×8 block boundaries sharpen on each pass, ringing accumulates near sharp edges, gradients band progressively. Cloudinary's classic 'Why JPEG is like a photocopier' study documents this generation loss empirically. Best practice: always compress from the original master rather than chaining compression passes. If the master is already a JPEG, compressing it once at quality 80 typically produces invisible loss while compressing the same JPEG twice at quality 80 visibly degrades. The tool uses the widely-used browser-image-compression library (Donaldcwl, MIT licence) which routes JPGs through Canvas toBlob('image/jpeg', quality), with optional Web Worker offloading via OffscreenCanvas. EXIF metadata (JEITA CP-3451X Exif 2.32) is stripped by default for privacy — opt-in preserveExif flag retains APP1 markers if needed.

Quality 1–100 mapped to ITU-T T.81 Annex K quantisation table scaling
Output JFIF v1.02 container (Hamilton 1992) — opens everywhere
EXIF metadata stripped by default (JEITA CP-3451X Exif 2.32) — privacy benefit; opt-in preserveExif available
Web Worker offloading via OffscreenCanvas (non-blocking batch processing)
Real-time size comparison with percentage savings before download
browser-image-compression library (Donaldcwl, MIT)

Free. No signup. No file uploads. Ads via AdSense (consent required).

Sources (6)

ITU-T (CCITT) Study Group VIII & ISO/IEC JTC 1/SC 29/WG 10 (JPEG) (1992). Information technology — Digital compression and coding of continuous-tone still images: Requirements and guidelines. ITU-T Recommendation T.81 (18 September 1992) / ISO/IEC 10918-1:1994 — Annex K quantisation tables map quality 1–100 to DCT coefficient scaling; lossy by design.
Hamilton, E. (C-Cube Microsystems) (1992). JPEG File Interchange Format (JFIF) Version 1.02. 1 September 1992 — de facto JPEG container; APP0 marker for density (DPI) + thumbnail; preserved through Canvas re-encoding by toBlob('image/jpeg', quality).
JEITA / CIPA (2019). Exchangeable image file format for digital still cameras: Exif Version 2.32. JEITA CP-3451X / CIPA DC-X008-2019 (revised 17 May 2019) — JPEG APP1 EXIF metadata; Canvas-based re-encoding strips EXIF by default; browser-image-compression preserves EXIF as opt-in option.
WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (toBlob('image/jpeg', quality) where quality ∈ [0,1] maps to T.81 Annex K Q-table scaling; re-encoding always introduces additional generation loss).
Donald (Donaldcwl) (live). browser-image-compression. npm package v2.0.2 (github.com/Donaldcwl/browser-image-compression, MIT) — Canvas-based JPG re-encoding pipeline used by this tool.
Sneyers, J. (Cloudinary) (2016). Why JPEG is like a photocopier. cloudinary.com/blog/why_jpeg_is_like_a_photocopier (4 May 2016) — empirical study of JPEG generation loss across re-encoding passes; quantisation rounding accumulates each pass.

These are the W3C, ISO/IEC, ITU-T, and IETF specifications the tool implements or builds on. Locate them on w3.org, iso.org, itu.int, or datatracker.ietf.org.