How to Tell if a Video Has Been Re-Encoded

Why this question comes up

A video passes through several hands and arrives back at you. It plays fine, it is the right length, the resolution matches. But somewhere along the way it may have been decoded and re-encoded — by an editor, a messaging app, an upload pipeline, or someone who opened it and hit export.

Every re-encode is generational loss. The second encoder does not see your original footage; it sees the first encoder’s output, artefacts included, and compresses that. Do it a few times and the degradation compounds badly.

If you are handing a master to a client, archiving a deliverable, or accepting footage into a workflow, “has this already been through an encoder” is worth knowing.

The things that do not answer it

File size. A re-encode at a higher bitrate can be larger than the original while carrying less real detail. Size tells you about the container, not the content.

Resolution and frame rate. Both survive a re-encode unchanged. A 1080p25 file that has been through three encoders is still 1080p25.

The codec name. H.264 in, H.264 out. Same codec, worse picture.

Metadata. Sometimes an encoder leaves a signature in the file’s metadata, and it is always worth a look. But metadata is trivially stripped or forged, and its absence proves nothing.

None of these look at the picture. That is where the evidence is.

What a second encode actually leaves behind

Blocking on top of blocking. Every block-based codec divides the frame into blocks. On a re-encode the second pass places its blocks on content that already has block edges in it — and those edges are strong features, so it tries to preserve them. The result is a doubled, sometimes misaligned block structure that no single encode produces.

Smeared fine texture. Grain, skin texture, foliage and fabric are expensive to encode and get thrown away first. A first encode thins them; a second removes what is left. Flat, plasticky texture in areas that should have detail is a strong sign.

Ringing around hard edges. Halos next to high-contrast boundaries — text, titles, sharp silhouettes — get reinforced with each pass.

Banding in gradients. Skies and soft lighting lose precision each time. Smooth becomes stepped.

Proving it against an original

If you have the original, this stops being detective work and becomes measurement. Upload the original and the suspect file to DiffALL’s video comparison.

You get a similarity score, a per-second chart, and a difference heatmap. What you are looking for is characteristic:

A high but not perfect score, with difference concentrated in detailed areas. That is compression loss. If the two files were the same encode, the score would be essentially 100%. If the content genuinely differed, the difference would be shaped like objects — not like texture.

Difference that follows a block grid. The heatmap showing a regular rectangular pattern is compression, not content. This is the clearest single signature there is.

A per-second chart that dips on high-motion shots. Encoders spend fewer bits where there is more movement, so a re-encode degrades most exactly where the action is. A chart that tracks the motion in your footage is describing an encoder, not an edit.

Compare that with what a content change looks like: a sharp drop at a specific second, difference concentrated in one region of the frame, and normal similarity everywhere else.

Without an original

Harder, but not hopeless. Two practical approaches:

Compare against a controlled re-encode. Take the suspect file, encode it once yourself at high quality, and compare the two. If the file was already heavily re-encoded, your extra pass changes relatively little — the detail it would have destroyed is gone. A pristine source degrades more from the same treatment.

Compare a still against a known-clean source. If any frame exists elsewhere at original quality — a publicity still, a thumbnail, a frame from another copy — image comparison on that single frame tells you a lot about the whole file.

What a result does and does not establish

A comparison establishes that two files differ, and characterises how. It does not establish intent, who did it, or when. Compression artefacts are evidence of processing, not of tampering — plenty of entirely innocent pipelines re-encode video as a matter of course.

If your question is whether the content was altered rather than merely recompressed, that is a different analysis: see how to spot edited or tampered images for the equivalent reasoning on stills.

Try it

Compare two videos → — upload the original and the file you are checking, and read the heatmap. Block-shaped difference concentrated in detailed areas means an encoder, not an editor.