YouCut does not add a watermark. That is not our opinion; it is what the app's own store listing says, in the developer's words: "As a free music video editor and full screen video maker for YouTube, YouCut never add Watermark to your video." So a mark in your exported file came from somewhere else, and there are only four places it can come from:
1. An overlay on your own timeline - a sticker, a text layer, a logo, or a watermark template sitting on a track above the footage.
2. A clip you imported that already had a mark on it - the mark was in the file before the editor ever opened it.
3. A third-party project template that ships its own logo.
4. The file's metadata layer - not a visible mark at all, just tags in the container.
The first three are pixels, and the fix is to stop compositing them and export again. The fourth is the layer this site's cleaner actually removes. Getting those two mixed up is the whole reason people buy the wrong tool for this job.
| Source | How to confirm it | What removes it |
|---|---|---|
| An overlay on your timeline | Open the project and look at the track list: the sticker, text or logo sits on its own track above the footage. Hide that track and the mark disappears from the preview. | Delete the layer, export again - one generation, nothing repaired |
| A clip that already carried a mark | The mark is in the source file before it ever enters the project. Preview the imported file on its own. | Only if you can obtain a clean source. Otherwise it is pixels |
| A template's own logo | Remove the template's logo layer. If the project will not preview without it, the template is the mark. | Rebuild without it, or crop the marked strip off |
| The container's metadata tags | Nothing on screen. It shows up in a file inspector, never in the picture. | This site's cleaner - measured below |
The top three rows all end with the same advice, and it is the cheap advice: fix it in the project, not in the file. The same four-way split applies to any editor, so the shape of the answer travels: the three layers a video mark can live in →
YouCut is a multi-layer timeline editor - its own feature list advertises a multi-layer timeline, chroma key, stickers, text, and ready-made templates. That feature set is also the explanation. An editor exports the timeline: every track above the footage is composited into the output, and the footage track underneath keeps its original frames untouched. So the software is not stamping your video. It is faithfully rendering a mark that something on the timeline put there.
That distinction decides what the fix costs. If the mark is a layer, the correct repair is not a repair at all: hide or delete the overlay, export again, and what comes out is your footage plus one generation of compression. Measured on the fixtures below, one generation scores 44.22 dB against a lossless render of the same timeline - that is the price of exporting at all, and it is a price you were going to pay anyway.
Because "watermark" searches often land on metadata tools, it is worth separating the two layers with a measurement rather than an assurance. The test file below was built to carry both at once: a logo composited over the picture, and ordinary container tags written by the muxer. Then this site's own container cleaner was run over it.
freed /moov/udta/meta/ilst/(c)nam = "holiday clip" 36 bytes freed /moov/udta/meta/ilst/(c)ART = "phone editor" 36 bytes freed /moov/udta/meta/ilst/(c)too = Lavf63.1.101 36 bytes freed /moov/udta/meta/ilst/(c)cmt = "exported from a phone editor" 52 bytes file size 511,507 -> 511,507 bytes video payload 5146aeb7bcab1de3385f78b545947c88 (unchanged)
Four tags out, and the picture byte-for-byte identical. An independent read of the two files with ffprobe confirms the same thing from outside our own code: before the clean the container reports title, artist, encoder and comment; after the clean none of those four keys is present, and the video payload's MD5 has not moved.
That is exactly what a container cleaner is for, and exactly why it cannot help with a mark drawn over the image. Metadata and pixels are different layers, and a logo composited onto the picture lives in the second one. What the container layer holds, and how to strip it without re-encoding →
The test builds the situation people actually get stuck in: a source timeline, a logo composited over the picture, and then the two routes out of it.
| Route | What it produces | PSNR against a clean render |
|---|---|---|
| Export again with the overlay layer hidden | The clean render itself - one generation | 44.22 dB against the lossless timeline |
| Leave the flattened export as it is | The marked file, untouched | 25.77 dB |
| Patch the flattened export, then encode again | A repaired file - two generations | 25.71 dB |
| - outside the logo box | Pixels you never touched | 49.87 dB |
| - inside the logo box | The interpolated fill | 10.01 dB |
Read rows two and three together, because that is the honest headline and it is not the one a remover tool wants to print. The patched file scored 25.71 dB against a clean render. The watermarked file it was made from scored 25.77 dB. The repair recovered essentially nothing: the interpolated fill inside the box (10.01 dB) is no closer to the original than the mark it replaced (10.04 dB), and the whole frame paid for a second encode on the way - the untouched area outside the box fell from 51.62 dB to 49.87 dB for no reason at all.
Now look at what the mark damages before anyone touches it. Comparing the watermarked export against the clean one:
whole frame 25.77 dB outside the mark's box 51.62 dB inside the mark's box 10.04 dB
The damage is confined to one rectangle. Outside it the two files are effectively the same picture - which is the strongest argument for the project route, because the only thing wrong with your file is a rectangle that a layer put there, and a layer is a switch.
The fixtures are built with ffmpeg at 960x540, 25 fps, 3 seconds, H.264 CRF 23 preset medium, with the logo modelled as a 220x62 overlay at (700, 452) in the bottom-right corner:
ffmpeg -f lavfi -i testsrc2=size=960x540:rate=25:duration=3 \ -c:v libx264 -qp 0 -pix_fmt yuv420p master.mp4 ffmpeg -i master.mp4 -i logo.png -filter_complex "[0:v][1:v]overlay=700:452" \ -c:v libx264 -crf 23 -preset medium -pix_fmt yuv420p \ -metadata title="holiday clip" -metadata artist="phone editor" \ -metadata comment="exported from a phone editor" marked.mp4 ffmpeg -i marked.mp4 -vf "delogo=x=701:y=453:w=218:h=60" \ -c:v libx264 -crf 23 -preset medium -pix_fmt yuv420p patched.mp4 ffmpeg -i clean.mp4 -i patched.mp4 -lavfi psnr -f null -
Two disclosures, because they change how you read the table. First, this machine cannot run YouCut - it is a phone app, and the fixtures model the compositing step with ffmpeg rather than coming out of a YouCut export. What transfers is the layer structure, not the bit-exact numbers. Second, testsrc2 has fine detail in every corner, which is the worst possible case for an interpolating fill: a real clip with a flat sky or a plain wall behind the mark would score considerably better than 10.01 dB inside the box. The loss outside the box is not pattern-dependent, because it is just an extra encode.
Autocomplete shows people hunting for a modified build. Two honest reasons to stop looking. First, there is nothing to unlock: the app's own listing states that it never adds a watermark to your video, so a modified build cannot remove something the official build never drew. Second, an APK from outside the store is the one download on your phone you cannot audit - and on the device that holds your camera roll, that is a bad trade even when it works. If a mark is in your file, it is in the picture, and no build of the app removes pixels that are already composited into the frames.
If the mark turns out to be from a different editor, the layer logic is identical and this site has the same walkthrough for each: CapCut, InShot, Premiere Pro, Final Cut Pro.
No. The developer says so in the app's own Google Play listing, in these words: "As a free music video editor and full screen video maker for YouTube, YouCut never add Watermark to your video." The listing repeats the point in its feature list under a "No Watermark" heading. So if your export carries a mark, it was composited into the picture from something on your timeline, or it was already in a clip you imported, or it is not a visible mark at all but a tag in the file's container. Those three cases need three different fixes, which is why the first job is to identify the layer rather than to download a tool.
Because something in the picture put it there. A multi-layer editor exports the timeline, so a sticker, a text layer, a logo, or a template's mark that sits on a track above the footage is composited into the output - that is what exporting means. The other common source is the footage itself: if you imported a clip that already carried a mark, the mark was in the file before the editor opened it. A third source is a downloaded project template that includes its own logo layer. The two-minute test is to hide the overlay track in the preview: if the mark disappears from the preview, it was on your timeline and it is yours to delete.
Find the layer first, because the answer changes completely by layer. If the mark is an overlay on a track above the footage, hide or delete that clip and export again: the footage track still holds the original frames, so the new export is clean and nothing has to be repaired. That costs one generation of compression, which the measurement above puts at 44.22 dB against a lossless render - the price of exporting at all. If the mark is already burned into the only copy you have, you are in pixel territory: crop it off if it sits in a strip you can spare, or accept a patch that invents the pixels it covers. The table above shows what that patch actually buys you, which is very little.
No, and our own measurement shows the separation in one line. The cleaner removed four container tags and left the video payload at exactly the same MD5 - 511,507 bytes in, 511,507 bytes out, not one pixel touched. Container metadata and picture content are separate layers, and a mark drawn over the image lives in the picture layer, so a metadata tool changes nothing about it. What metadata stripping is genuinely good for is the other half of the problem: the tags that record which application wrote the file, what it was called, and when it was exported.
No, and it is the wrong question. The official app already states that it does not add a watermark to your export, so there is nothing a modified build could unlock - you would be taking a risk to remove a mark the official build never drew. What a sideloaded APK does add is a download you cannot audit, installed on the device that holds your photos and your accounts. And even if a build did suppress an overlay at export time, it could not touch a mark that is already composited into the frames of a file you have. We do not link to any such file.
Then you are choosing between two honest options, and neither of them is a restoration. Crop: if the mark sits in a strip you can spare, cut the frame down and every pixel you keep is real. Patch: cover the region and let the editor invent the fill, accepting that the whole frame pays for a second encode. The measurement above is the argument for both. A patched export scored 25.71 dB against a clean render, and the watermarked file it came from scored 25.77 dB - there is nothing to recover, because the marked pixels were overwritten when the mark was composited. If you still have the project, or can get the original footage, that route beats both options by a wide margin.