A phone clip is the other shape, and that changes the arithmetic of every route. Measured on a 1080x1920 clip with a 268x80 mark in the bottom-right corner, cropping the bottom strip costs 5.83% of the picture and cropping the side strip costs 27.78% — a 4.8x spread decided entirely by which edge you pick. On a landscape clip of the same mark the two edges differ by only 1.5x, so the phone shape does not make cropping worse in general; it makes the choice of edge matter about three times more.
The other two routes do not care about the shape, but they cost what they cost, and both are measured below: painting over the mark scores 16.61 dB against the clean picture, and carrying the real pixels back from other frames of the same shot scores 37.98 dB. One rule applies to all of them on a phone: a crop is always a re-encode, because a filter and a stream copy cannot be used in the same command — ffmpeg says so in as many words, and the refusal is quoted further down.
A phone held upright records a frame that is taller than it is wide. This page uses 1080x1920, the shape that produces, and every percentage below is a share of that frame — so it holds for any resolution with the same 9:16 ratio.
Two things change. The first is geometry: a crop is a full strip, and a narrow frame makes the side strips expensive. The second is that there is no command line on a phone, so the file can only be changed by an app — and any app that changes pixels has to decode and re-encode the whole frame, which is a cost you can measure before you pick one.
Two things do not change. The mark is still paint on the frames, in the same two places it can be on any clip: the container and the pixels. And the container layer is still the one that comes off without touching a picture, which matters more on a phone than anywhere else, because that one can be done in a browser with no app at all.
The mark on this fixture is an 11-character wordmark, a 6 px gap and a 40x40 logo square, anchored to the bottom-right corner — the shape and position a free editor or a recording app uses. It covers 5,360 px, 1.03% of the frame. The crop bill has nothing to do with that number, because a crop cannot take just the mark:
| Strip that clears the mark | Size at 1080x1920 | Share of a 1080x1920 frame | Share of a 1920x1080 frame |
|---|---|---|---|
| the bottom strip | 1080 x 112 px | 5.83% | 10.37% |
| the side strip | 300 x 1920 px | 27.78% | 15.62% |
| the two edges differ by | — | 4.8x | 1.5x |
Read the middle and right columns together, because that is the whole finding. The mark is the same mark and the strips are the same pixel sizes in both columns; only the frame shape changes. On the vertical frame the two choices are 5.83% and 27.78%, a spread of 4.8x. On the landscape frame they are 10.37% and 15.62%, a spread of 1.5x. So a phone clip does not make cropping worse across the board — it makes the choice matter about three times more, and it happens to make the bottom edge the cheap one. Since a phone app puts its mark in a bottom corner, that is the one place where a tall frame is on your side.
The bill is bigger than the mark either way: 5,360 px of mark against 120,960 px for the bottom strip (22.6x) or 576,000 px for the side strip (107.5x).
And neither crop leaves you a 9:16 clip. 1080x1920 is 0.5625. Cropping the bottom gives 1080x1808 = 0.5973; cropping the side gives 780x1920 = 0.4062. A platform that expects 9:16 will letterbox or pillarbox what you upload, so part of the strip you removed comes back as black bars — which is worth knowing before you decide the crop was free.
On a desktop the tempting move is to cut the strip off without touching the picture. That is not available, and the tool says so rather than doing something surprising:
ffmpeg -i marked.mp4 -vf "crop=540:904:0:0" -c copy cropped.mp4 Filtergraph 'crop=540:904:0:0' was specified, but codec copy was selected. Filtering and streamcopy cannot be used together. exit status: non-zero
A filter changes the frames; a stream copy copies them. So the command is refused, and the refusal is the answer: a crop decodes and re-encodes every frame it keeps. What a crop actually buys is that nothing inside the surviving picture is invented — no interpolation, no borrowed pixels, no guess. That is a real advantage and it is a smaller claim than being lossless. It is also why the page on the three pixel routes calls crop the one that costs picture rather than quality.
The same is true of every app on a phone, for the same reason: a container stores encoded frames, not movable pixels, so any change to the picture is a new encode of the whole frame.
Since every phone route re-encodes, it is worth knowing what one generation of re-encode costs, measured on this fixture against the file it came from:
clean vs one more generation 50.59 dB clean vs two more generations 48.70 dB clean vs the marked file 25.93 dB (whole frame) mark box, marked vs clean 6.14 dB
The first line is the price of the app itself, paid on every pixel in the frame whether the app touched it or not. The third line is the mark, and it is the one that looks alarming for a bad reason: the mark is 1.03% of the frame, so a whole-frame average is dominated by the pixels nobody marked. The fourth line is the one to judge any method by, because it looks only at the mark's own box.
One honesty note on the fixture: it is built with deliberately fine detail in both directions, which is the hardest case for interpolation and a demanding case for the encoder. On a smooth clip the same commands score higher. That is why the numbers below are quoted against a clean render of the same clip rather than as absolutes.
Both routes keep the frame and the 9:16 shape, so neither forces the letterboxing problem. They differ in where the pixels come from:
| What you do to the mark's box | Score against the clean picture | What it costs |
|---|---|---|
| Nothing — the mark stays | 6.14 dB | — |
Paint over it — interpolated from the ring, what delogo does | 16.61 dB | a re-encode of every frame |
| Carry it back — real pixels from other frames of the same shot | 37.98 dB | a re-encode, and the background has to move behind the mark |
Both are re-encodes, and the part of the frame neither one writes to differs from the marked input by 50.65 dB (after the patch) and 50.62 dB (after the recovery), which is the re-encode alone. The gap between the two rows is the difference between a guess and a record: the patch invents a plausible continuation of the pixels around the box, and the recovery finds the same piece of background in frames where the mark was not on it.
That second route needs one condition you can check by watching the clip: the background has to slide behind the mark by at least the mark's own width during the shot. The fixture pans 180 px behind a 134 px mark, which is 1.34x, and every covered pixel turns up unmarked in some other frame. A locked-off shot of a still scene has no answer at all, and then the patch is the whole choice.
One thing we could not find, stated as a limit rather than a fact about any product: no phone app we looked at offers that second route. It needs the background's movement estimated in every frame, which is the expensive half of the job, and the free tier of an app can afford the patch instead. The page on blur versus inpainting measures why the cheap route looks the way it does.
A video file can carry records that have nothing to do with the picture — a C2PA provenance box, a title, an artist, a comment, and the offset table that tells a player where each frame starts. Those live in the container, next to the video track, so they can be rewritten without decoding a single frame. That is the layer a phone browser can handle: the tool on the free video watermark remover page reads an MP4 or MOV in the browser, on the phone itself, and lists what it found before it changes anything. Nothing is uploaded and there is no account.
What it cannot do is worth saying plainly, because the two get confused constantly: it does not touch the picture. If the mark you can see is still there after you run it, that is not a bug. You removed one layer and looked at another. The video metadata page walks through what each container method leaves behind, including the offset-table failure that corrupts a file when a box is deleted rather than rewritten in place.
There is one route that looks like it escapes all of this. If the mark is drawn over the picture rather than painted on top of it, the picture underneath is still in the file, scaled down, and the blend can be inverted:
observed = alpha * mark + (1 - alpha) * original original = (observed - alpha * mark) / (1 - alpha)
The mark on this fixture is drawn at 95% opacity, so the original survives at 5% of its value and the inversion divides by 0.05 — multiplying whatever error the file already carries by twenty. Measured on the decoded files, over the pixels the mark actually covers, using the fixture's true opacity:
mark box, do nothing (decoded) 6.05 dB inverted, opacity assumed 0.90 9.36 dB gain +3.31 dB inverted, opacity assumed 0.94 16.35 dB gain +10.29 dB inverted, opacity assumed 0.95 19.45 dB gain +13.39 dB <- the true value inverted, opacity assumed 0.96 15.58 dB gain +9.53 dB inverted, opacity assumed 0.97 11.71 dB gain +5.65 dB
Even at the exact right opacity the result is 19.45 dB: a smeared patch, not the original picture, because the one level of error H.264 leaves behind comes back as twenty. Move the assumed opacity by a hundredth of a point and the gain roughly halves. A near-opaque mark is the phone case, so this is a dead end there. It is not a dead end in general — at 55% opacity the leftover is large enough for the division to be worth doing, and the logo page measures that case with its own table of what a wrong opacity costs.
No phone was used to produce any number here, and no app was installed. The fixture is built on this machine, the mark on it is synthesised, and every figure comes from a real run of ffmpeg on that fixture, reproducible with the script named at the end. So the numbers describe the frame and the container, not any particular product, and nothing here is a review of an app.
What the page can tell you is which of the routes is open to you and what each one costs on a clip of this shape, which is the part that desktop guides get wrong: they were written for a frame that is twice as wide, where the side strip is cheap. It cannot recover the pixels under a near-opaque mark, and no tool can, on a phone or anywhere else. The check worth running before you pay anyone is on the page about what a removal does to the rest of the file: whether the audio track, the subtitles, the duration and the frame rate came through unchanged.
If the clip came off a platform rather than out of a camera, the platform's own page is the better start: a saved TikTok and a downloaded Reel each carry a mark in a place and a form of their own.
For the container layer, yes: the records a file carries live in boxes next to the video track, and a browser can rewrite those boxes on the phone itself with nothing uploaded and no account. For a mark you can see on the frames, no. Changing pixels needs a decode and a re-encode, which is what an app does, and there is no way around it from a browser. The useful first step is therefore not finding an app but finding out which of the two you have, which the browser tool on this site does before it changes anything.
Because a crop takes a full strip, and a vertical frame is narrow. Measured at 1080x1920 with a 268x80 mark in the bottom-right corner, the strip that clears the mark from the bottom is 112 px tall, which is 5.83% of the picture. The strip that clears it from the side is 300 px wide, which is 27.78% of the width. Same mark, same pixels, and the two edges differ by 4.8x. On a 1920x1080 frame the same mark costs 10.37% from the bottom and 15.62% from the side, so the two edges differ by only 1.5x. The phone shape does not make cropping worse in general; it makes the choice of edge matter about three times more, and it happens to make the bottom edge the cheap one.
No, and it is easy to check. ffmpeg refuses to put a filter and a stream copy in the same command, and the refusal is the answer: a filter changes the frames and a stream copy copies them. The command below exits non-zero with "Filtergraph 'crop=540:904:0:0' was specified, but codec copy was selected. Filtering and streamcopy cannot be used together." So a crop decodes and re-encodes every frame it keeps. What a crop really buys is that nothing inside the surviving picture is invented, which is a different and smaller claim than being lossless.
We could not find one, and the reason is arithmetic rather than marketing. Not blurring the mark means either cropping (which every app can do) or putting the real pixels back from other frames, and the second one needs the background tracked frame by frame, which is the expensive part of the job. What the free tier of an app can afford is a box filled from the pixels around it, which is exactly what ffmpeg's delogo does and which measured 16.61 dB against the clean picture on this fixture. Carrying the real pixels back from other frames of the same shot measured 37.98 dB on the same clip, and no app we looked at offers that route.
Because it is near opaque, and near opaque means the pixels under it are gone. The mark on this fixture is drawn at 95% opacity, so the original picture under it survives at 5% of its value. Inverting the blend divides by 0.05, which multiplies whatever error the file already has by twenty: measured on the decoded files, the best inversion reached 19.45 dB against the clean picture, against 6.05 dB for leaving the mark alone. That is a smeared patch, not a recovery, and moving the assumed opacity by a hundredth of a point drops it to 15.58 dB. There is no third route hiding behind the corner mark.
Yes, by a fixed amount, and you can put a number on it before you start. Any app that changes pixels writes a new encode of the whole frame, and on this deliberately detailed fixture one more generation of H.264 at the same setting cost 50.59 dB against the file it came from, with a second generation at 48.70 dB. That cost lands on every pixel, including the ones the mark never touched, so it is paid whether you crop or patch. What survives untouched is the audio and the container records: the audio track is not re-encoded by a video edit, which is measured on the page about what a removal does to the rest of the file.