A DJI watermark is two unrelated things, and only one of them can be removed. The DJI logo is drawn by the DJI app when it exports or edits your clip — it is a switch in the app, and once it is in the frames no tool puts the pixels back. The flight record is different: every DJI file also carries machine-readable data — XMP in the drone-dji namespace on photos, user-data atoms in the container on video — that says where the aircraft was and where the camera pointed. That layer is data, not picture, and it comes off without a re-encode.
So "remove the DJI watermark" is two jobs. One of them is a setting, one of them is a file clean, and neither of them is a website that un-draws a logo.
"Remove the DJI watermark" gets used for two different problems, and they do not have the same answer. One is a logo you can see. The other is a record you cannot, sitting in the file next to the picture. Working out which one is bothering you decides what is even possible.
| Layer | What it actually is | Where it comes from | What removes it |
|---|---|---|---|
| The DJI logo | Pixels, drawn over the frames | The DJI app's watermark setting, at export | Turn the setting off and export again — or crop, cover, inpaint |
| The flight record | Data beside the picture, not in it | The camera, written at capture | A metadata clean, locally, with no re-encode |
The reason the distinction is worth ten seconds of your time: the first layer cannot be removed by anything, including this site, because it is already part of the picture. The second layer is not part of the picture at all, which is why it comes off cleanly and why it is the only half of the problem a page like this can honestly help with.
This is the part that surprises people, and it is the reason the free fix usually works. DJI documents the watermark as a feature of its own apps rather than of its cameras: the DJI Mimo app page lists a frame watermark that stamps the device model onto a clip, and DJI's support centre publishes a guide for adding a watermark on its handheld devices. A feature you can turn on is a feature you can turn off.
What follows from that is the useful part:
One honest caveat, because it decides whether the free route is open to you: this only helps if you still have the footage or the project. If the file you are holding is the finished export and the original is gone, the logo is pixels, and the pixels underneath it were never recorded. At that point your options are the three in the table below, and all three change the picture.
| Route | What you get | What it costs |
|---|---|---|
| Turn the watermark off, export again | The frames you actually shot, no logo | Nothing from the picture — this is the real answer |
| Crop the marked strip off | Only real pixels, in a smaller frame | A strip of the picture, and a re-encode |
| Cover it with a title or sticker | The full frame, with one hidden rectangle | A visible block wherever the background is not flat |
| Hand the file to a remover site | A re-encoded repair | Picture quality, plus the upload |
Measured elsewhere on this site, the cover route is the one that quietly fails on a mark that moves: a fixed box over a travelling mark left it on screen in 63 of 72 frames. What actually avoids a blur box →
DJI files carry a second, quieter mark, and unlike the logo it is not a setting. It is written at capture, it is machine-readable, and it is public enough that the tooling to read it already ships.
On photos, DJI writes XMP into a drone-dji namespace. ExifTool documents that group, and the tag names are the giveaway: AbsoluteAltitude, RelativeAltitude, GpsLatitude, GimbalYawDegree, GimbalPitchDegree, FlightYawDegree, RtkFlag, CalibratedFocalLength. Read together, those fields say how high the aircraft was, where it was, and exactly where the gimbal was pointing — a flight log attached to the picture.
On video, the same idea lives in the container. ExifTool describes djmd and dbgi as protobuf-format DJI timed metadata, and the embedder documentation notes that newer models such as the Air 3S and Mini 5 Pro record their telemetry inside the MP4 as exactly that track, with no sidecar file. Older cameras lean on ordinary QuickTime user-data atoms instead. DJI's own developer site publishes a Media File Metadata whitepaper describing the format, and names DJI Action 2, Mavic 3, Matrice M30 and Ronin 4D among the products that follow it.
None of that is a defect, and none of it is in the picture. It is a record, and records can be removed. The two experiments below do exactly that and check the pixels while they are at it.
The file is built here, not downloaded: a 1600×1200 frame carrying the EXIF a DJI camera writes (Make=DJI, Model=FC3411, a GPS IFD, and Orientation=6) plus an XMP packet in the drone-dji namespace with the real tag names above. Then the local cleaner — the same cleaner.js the browser tool on this site runs — is pointed at it from Node, so the bytes can be read back.
input 49429 bytes APP1(Exif) len=380, APP1(XMP) len=661, APP0(JFIF), image data
after the local clean 48420 bytes APP0(JFIF), APP1(Exif) len=34, image data
removed exif=1 xmp=1
kept JFIF header, JPEG image data, EXIF orientation tag
string scan drone-dji / AbsoluteAltitude / RelativeAltitude / GimbalYawDegree /
FlightYawDegree / GpsLatitude / RtkFlag / FC3411 / v01.00.0000 / DJI
-> every one present before, absent after
scan data 47775 bytes md5 6ea2ebe9063678793ab3c28e87bbeee9 (identical before and after)
decoded 1600x1200, pixels identical, sha256 d9e5f3ac64f899591f50dc371b4d1372
orientation 6 -> 6
Three things in that output are the whole point. Every DJI string is gone from the bytes — not the logo, the record: the drone-dji namespace, the altitude, the gimbal angles, the aircraft code FC3411, the firmware string. The compressed image data, which is everything from the start-of-scan marker to the end of the file, came out byte-for-byte identical at the same MD5, because a metadata clean is not a re-encode and never touches the picture. And Orientation is the one tag the cleaner deliberately puts back, so a portrait shot does not arrive sideways after being cleaned.
That last detail is the difference between a clean file and a broken one, and it is worth knowing which way your tool went. Strip a photo's metadata before sharing it → Remove EXIF data: what each method leaves behind →
The video side is the same idea in a different container. A short MP4 is written with the descriptive user-data tags an exporter adds, plus a QuickTime location atom (©xyz), which is the atom a camera writes for the capture point. Then the shipped video-cleaner.js is pointed at it.
input 275957 bytes 5 user-data boxes
after the local clean 275957 bytes 0 user-data boxes
freed /moov/udta/meta/ilst/©nam (c)nam = DJI_0001.MP4
/moov/udta/meta/ilst/©ART (c)ART = DJI
/moov/udta/meta/ilst/©too (c)too = Lavf63.1.101
/moov/udta/meta/ilst/©cmt (c)cmt = FC3411 v01.00.0000
/moov/udta/©xyz location = +37.7749-122.4194/
location string before=present after=gone
mdat payload md5 86208c2b5c24a2c4cefd807d1cbb2aa6 (identical before and after)
Again the file does not get smaller — 275,957 bytes in, 275,957 bytes out — because each box is rewritten in place as a free box of the same size rather than deleted. That is deliberate: removing bytes would shift every later byte while the chunk offset table inside moov kept its old absolute positions, and the video would stop playing. And the mdat payload, which holds every frame, came out with the same MD5, because a container edit is not a re-encode.
Two boundaries belong in the same breath, because a page that only lists its wins is not worth reading. First, the cleaner frees QuickTime user-data atoms (the © family) and uuid boxes; ffmpeg's own loci location box is not in that family, and the same run left it alone. Second, and more important for a drone: the cleaner does not target the newer djmd / dbgi protobuf telemetry track at all, because it is neither a user-data atom nor a uuid box. On an Air 3S or Mini 5 Pro clip, the telemetry is that track. Check which one your file actually carries before assuming a clean took everything. Remove metadata from a video without re-encoding → Strip image metadata without re-encoding →
Three honest limits, stated plainly, because the alternative is a page that oversells a tool.
If what you are weighing is a one-off clean against handing your footage to a website, the difference is the upload. A drone clip usually contains a home, a street, and sometimes a face; the record that says where it was taken is precisely the thing worth not posting to a stranger. The cleaner here runs on your device →
djmd / dbgi track before assuming a container clean covered it.Because the DJI app has a watermark feature and it was on. DJI's own app pages describe a frame watermark that stamps the device model onto a clip, and the support centre publishes a guide for adding a watermark on handheld devices. It is a setting you can switch, not a fee you have to pay and not something the sensor records. The camera writes the picture; the app draws the logo over it on the way out.
In the app that produced the file, not in the file. DJI Mimo covers the handheld cameras (Osmo Pocket, Osmo Action, Osmo Nano, Osmo 360) and DJI Fly covers the drones; both export through a screen that has a watermark switch next to the resolution and frame rate. Switch it off and export again. The clips you recorded are untouched by the logo, so a second export from the same footage is a clean copy rather than a repair.
Only by changing the picture. Once the export is done the logo is part of the frames, and no tool can recover the pixels that were underneath it. The three things that physically work are to crop the marked strip off, to cover it, or to re-encode the clip with an inpainting pass that invents replacement pixels from the surrounding frame. If you still have the footage on the card or in the app, exporting again without the watermark is strictly better, because it renders the frame you actually shot.
No, and they are not even the same kind of thing. The logo is pixels; the flight record is data sitting beside the picture. Measured here, the two never touched each other: a metadata clean removed the XMP packet and the container tags while the compressed image data came out byte-for-byte identical, and it left the logo in place because the logo was never a record to begin with. If you want both gone you need two operations, and only one of them can be done without losing picture.
It is the flight record DJI writes into the file, and it is public enough that the tooling to read it already exists. ExifTool documents a drone-dji XMP group on DJI photos with tags such as AbsoluteAltitude, RelativeAltitude, GpsLatitude, GimbalYawDegree, GimbalPitchDegree, FlightYawDegree and RtkFlag, so the file can say how high the aircraft was and where the gimbal was pointing. DJI's developer site publishes its own Media File Metadata whitepaper describing the format, listing DJI Action 2, Mavic 3, Matrice M30 and Ronin 4D among the products that follow it.
For the flight record, yes, and it is a metadata clean you can run locally. For the logo, no, because a remover cannot un-draw a frame. Anything sold as a DJI watermark remover is doing one of three things to the picture: interpolating over the marked rectangle, cropping it away, or re-encoding the whole file, and all three are operations your own machine performs. The difference an online service makes is that it needs your footage first, and drone clips routinely carry more than a logo.