Images & photos · Browser Image & Drawing Editor
Lossless JPEG cropping vs browser cropping: why re-encoding happens
· Background
image-editing canvas browser-processing
Command-line tools can crop a JPEG without decoding it, but only on an 8- or 16-pixel grid; browser editors decode and re-encode instead. This post explains why both approaches exist and how to limit quality loss when you must re-encode.
Two crops, two file sizes — the same rectangle cut two ways produces different files, and the reason is in the JPEG format itself
Two JPEG crops can have the same dimensions and still produce different byte sequences. The rectangle may be identical while the encoder writes different tables, headers, quantised values, or metadata. The key distinction is the path taken. A lossless JPEG utility can sometimes rearrange compressed blocks, whereas this editor decodes the image, copies pixels into its raster layers, and asks canvas.toBlob to encode a fresh file.
Test that distinction with a duplicate rather than an irreplaceable scan. Crop a rectangle, export it, and compare the dimensions, visible edges, and measured blob size. JPEG quality is passed to the browser encoder; PNG receives no lossy-quality argument, and WebP follows its own browser codec. The download is a new encoding, not the original compressed stream with a corner removed.
How a JPEG is organised — 8×8 blocks, minimum coded units and why the grid matters for cutting
JPEG stores transformed image information in 8-by-8 blocks, with larger coding units shaped by sampling and the file’s organisation. That grid matters to specialised lossless operations because a cut may be clean only when its edges align with the structures the file already contains. It is useful format context, not a claim that the browser editor exposes block coordinates or understands minimum coded units.
The editor’s crop tool thinks in a source rectangle over decoded pixels. It can therefore represent an arbitrary selection, including one that lands between JPEG block boundaries, but the source does not expose subsampling controls, block alignment, or byte-level preservation. The result is convenient geometric freedom at the cost of returning to an encoder after the pixels have been drawn.
JPEG block structure is background context; this editor does not parse or crop compressed blocks
A tool such as jpegtran represents the other trade: it can operate on JPEG structure without first converting every block into ordinary pixels. When a crop edge fits the relevant block grid, the tool may discard complete regions while leaving the remaining compressed data intact or avoiding a full lossy re-encode. That workflow is outside this editor and should not be implied by a generic browser crop button.
Lossless does not mean arbitrary. Block-aligned tools may constrain the crop rectangle, and metadata handling still needs its own verification. The editor makes a different choice: it gives the user a free rectangle on the decoded image, copies that rectangle into new layer canvases, and later encodes the result. Use a dedicated JPEG utility when byte preservation or block-level archival behaviour is the requirement.
Lossless JPEG cropping is outside this implementation and requires a different tool
Canvas editing is built for pixels, not JPEG transform coefficients. The browser loads the image as an HTML Image, the editor copies the selected source rectangle into new layer canvases, and the visible raster is composed for export. That design accepts any crop geometry and lets the same workflow handle drawings, text, and other layers. It also means the original JPEG blocks are no longer the export material.
When the session is exported, canvas.toBlob asks the browser for a new PNG, JPEG, or WebP file. For a JPEG download, that is a browser re-encode of the decoded and edited raster. The source does not expose minimum-coded-unit alignment, coefficient copying, subsampling selection, or a guarantee about metadata and profiles. The behaviour is deliberate raster editing, not lossless block cropping.
Browser cropping decodes pixels, copies a rectangle and re-encodes the composite
A single re-encode may be acceptable for a web image, but its cost depends on the source, crop, browser encoder, chosen quality, and content. Fine text, halftone scans, sharp line art, and repeated contrast edges can reveal changes sooner than a casual photograph. Avoid assigning a fixed percentage to the loss or a guaranteed file-size reduction: the repository provides no such promise.
Keep the workflow to one deliberate export when possible. Reopening a JPEG download, making another raster edit, and encoding it again compounds opportunities for artefacts, while exporting PNG may change size and format trade-offs rather than preserve JPEG bytes. Compare the actual output at useful magnification, retain the source, and choose the format and quality for the destination instead of trusting a universal number.
Re-encoding consequences are encoder-dependent; no fixed size or quality percentage is promised
Use a scanned page as a practical comparison. Preserve the original, note its dimensions and file size, then mark the desired rectangle in the editor. Export the crop once as JPEG at the chosen quality and inspect small type, straight borders, and paper texture. The output dimensions answer whether the page was trimmed; the visual inspection answers whether the new raster remains useful.
A lossless block-aware utility would be a separate experiment: it might accept only aligned edges and avoid decoding the page, while the browser crop accepts the rectangle you draw. Do not compare the two as if they had the same guarantee. Here, canvas.toBlob produces a new file, and the source does not promise byte identity, metadata retention, profile retention, or a fixed quality cost.
Worked check: compare dimensions and visible detail without expecting byte preservation
The comparison is specifically about a JPEG input and a browser raster crop. PNG has different compression behaviour and receives no lossy-quality argument in this editor. WebP follows its own browser codec. Rotation, metadata rewriting, ICC handling, and specialised lossless JPEG transforms are separate questions; a successful export in one format does not answer them for another.
The same caution applies to archival claims. The editor does not expose minimum-coded-unit alignment, subsampling controls, a lossless-rotation operation, or a guarantee that embedded metadata survives. If the source must remain structurally intact, keep it and use a format-aware tool. If the goal is a convenient new picture with an arbitrary rectangle, the browser workflow is the more direct fit.
Takeaway: know which trade you are making — how the Browser Image & Drawing Editor crops any rectangle on your device, and when a lossless tool suits archival work better
The trade is straightforward: this editor performs a raster crop followed by a new browser encoding. It decodes the image, copies the selected rectangle into its layer canvases, composites the visible result, and uses canvas.toBlob for the requested format. That gives you an arbitrary crop on the device, but it does not preserve the original compressed byte stream or claim lossless JPEG semantics.
Use it when the deliverable is a practical image for sharing, review, or further ordinary editing. Keep the source and choose a format-aware lossless utility when archival fidelity, block preservation, or metadata guarantees matter. Measure the final dimensions and inspect the visible detail; those checks describe the file you received without pretending that every browser encoder makes the same byte-level trade.