Images & photos · Image Converter & Compressor
JPEG generation loss: what happens when you re-save the same photo
· How it works
image-formats jpeg image-quality
Every lossy save discards information, and the discards accumulate: a photo saved ten times is not the same as a photo saved once at the same quality. This post explains why, what makes it worse, and how to structure a workflow so it happens once.
The image that got muddier each week — the slow decline nobody noticed until they compared the first and latest versions
A weekly campaign image can become dull and noisy when each new version starts from last week’s JPEG. The change may escape notice because nobody views generation one beside generation eight. ToolAcre’s format logic names the mechanism it can prove: JPEG is lossy at every quality, and re-encoding a JPEG adds another round of loss on top of the first.
Audit the workflow before debating one slider value. Locate the earliest retained source and list every operation that wrote another JPEG. A download, rename or copy causes no generation loss by itself; decode followed by encode does. That distinction often reveals an unnecessary export between crop, resize, approval and final delivery.
Why lossy is lossy — quantisation rounds the frequency coefficients, and rounding cannot be undone by decoding
The plan’s frequency-coefficient explanation is plausible background material, but those calculations are not present in this application. The browser owns the JPEG encoder. ToolAcre passes it canvas pixels, a MIME type and quality, then receives a Blob. The trustworthy claim is therefore behavioral: detail is discarded, and the discarded information cannot be restored by later choosing PNG.
Keeping the evidence boundary narrow does not weaken the recommendation. A lossy stage should occur only where a lossy delivery file is required. If an intermediate must be saved between tools, retain the original project or a lossless raster where practical. The next export can then begin from pixels that have not already survived an avoidable JPEG approximation.
The repository verifies lossy browser encoding, not JPEG coefficient mathematics
On a second save, the decoder produces pixels from the first JPEG and the encoder approximates those pixels again. The new pass has no access to the pre-JPEG source and cannot distinguish original detail from artefacts already introduced. ToolAcre’s warning explicitly calls this a second round rather than suggesting that identical format and quality leave bytes untouched.
A useful experiment keeps every generation instead of overwriting one filename. Start with a master, produce `round-1.jpg`, load that result for `round-2.jpg`, and continue. Compare each with the master and with its immediate parent. Separate files make gradual change visible and prevent the test itself from destroying its reference.
A second save is a second browser encode from decoded pixels
Cropping or resizing between saves introduces an additional pixel operation. In this code, changed dimensions mark the plan as resampled even when the destination encoder is PNG. `drawImage` redraws the selected source rectangle into the target geometry with high smoothing before encoding, so a dimension change should be recorded separately from JPEG’s lossy write.
The outline attributes extra damage to a shifted block grid, but this browser pipeline does not expose block alignment. The defensible procedure is to isolate variables: first repeat same-size JPEG export, then repeat with a resize. If the second sequence changes more, the observation belongs to that browser and test image without inventing an encoder-level explanation.
Resizing adds resampling; block-grid explanations are outside implementation evidence
Using the same quality number on every round does not create a safe harbour. The value is passed as an instruction to the current browser’s encoder; it is not a checksum, retained-detail percentage or promise that another encoder maps the number identically. The source records even warn that outputs can differ slightly among browsers and platforms.
Quality 100 is still classified as lossy for JPEG. Raising the number on a later generation may add bytes, but it cannot summon texture removed earlier. Choose quality by inspecting a first-generation delivery copy and its measured size. Once accepted, regenerate that copy from the master whenever content changes instead of using the accepted export as the next source.
Quality numbers are encoder inputs, not guarantees of equivalent quantisation
For a five-round demonstration, select a photograph containing a smooth sky, hair, foliage and high-contrast edges. Keep dimensions fixed and use one browser and one quality. Save each round with a numbered filename, then compare all six files at 100 percent in a viewer that does not apply additional editing.
Record the output bytes rather than claiming a predetermined growth or reduction. A later round can be smaller or larger depending on the pixels and encoder; size direction is not a quality score. Look for changes around detailed boundaries and smooth regions, and stop the experiment with the original still intact.
What this does not cover — lossless formats, which do not suffer this, and editing RAW or master files
Lossless destination encoding behaves differently, but converting a degraded JPEG to PNG only stores the degraded decoded pixels exactly. It does not reverse previous loss. RAW development, layered projects and camera-specific master workflows are outside this browser converter, which accepts JPEG, PNG, WebP and single-frame GIF input.
The tool also does not compare generations automatically or calculate a perceptual score. Its first-result before-and-after panes support visual review, while downloaded files allow a stricter native-size comparison. Treat those facilities as inspection aids, not certification that a chosen setting is archival.
Takeaway: keep a master, export once — how to use the Image Converter & Compressor as the final step rather than a repeated one
Keep one source of truth and make the lossy file a replaceable derivative. That simple ownership rule prevents a social calendar from becoming a chain of approximations. ToolAcre should be the final encode for a specific recipient or channel, not an invisible intermediate repeated after every small edit.
When a new variant is needed, reopen the master, apply all required geometry once and export once. Archive the settings or approval note rather than the damaged lineage. The browser can always create another delivery JPEG; it cannot reconstruct information that earlier generations threw away.