Bench

MP4 Tag Editor

beta

Add a title, artist, album, genre, year, comment and the music-video kind to an MP4 or MOV — written into the file itself, nothing re-encoded

How it works

Choose or drop an MP4, M4V or MOV. The tool reads the file's index (the moov box) and shows the tags it finds: title, artist, album artist, album, genre, year, comment and the media kind, plus the encoder name and a list of anything else it will keep untouched, such as cover art or lyrics. Edit the fields and save. The tags are written as the iTunes-style atoms every player and ffmpeg understand — ©nam, ©ART, aART, ©alb, ©gen, ©day, ©cmt and stik, exactly what ffmpeg writes from -metadata title=…, artist=… and media_type=6 — into moov/udta/meta/ilst, and a QuickTime file's older text atoms are kept in step so no reader sees a stale value. The video and audio are never decoded or re-encoded. How much of the file is rewritten depends on where the index sits: most recordings and ffmpeg exports keep it at the end, so only the last few hundred kilobytes change and the media stays put; a fast-start file keeps the index at the front, where the tool writes it in place if there is room and otherwise moves the media once, patching every chunk offset and leaving 16 kB of spare room so the next edit fits in place. In Chrome and Edge the save goes into the file you picked, through the File System Access API. A browser cannot change a file in place, so the save writes a fresh copy of the whole file in 64 MB pieces (measured faster than the browser's own copy, and the only way to see progress), then Chrome reads the copy back to check it before moving it into place, then the result is read once more to confirm the tags. A progress panel shows the stage in words, a bar, bytes written, elapsed, remaining and the expected finish, each stage's estimate and what it rests on — default guesses at first, then the copy and close rates learned from your earlier saves and video exports on this machine — and a stage that runs past its guess keeps promising a quarter of the time spent rather than zero. A 100 GB file means two passes over the disk, so expect minutes; the copy can be cancelled, which leaves the original untouched. Other browsers download a tagged copy instead, whose progress only the download manager shows. Nothing is uploaded.

Questions

Does it re-encode the video?

No. Only the index of the file changes; the video and audio bytes are copied exactly as they were, and the stream hashes before and after are identical. What a save costs is disk time: the browser writes a fresh copy of the file and reads it back once to check it, so a 100 GB export takes minutes, with the progress panel showing where it is and when it will finish.

Which tags does it write, and how do they show up in ffprobe?

Title (©nam → title), artist (©ART → artist), album artist (aART → album_artist), album (©alb → album), genre (©gen → genre), year (©day → date), comment (©cmt → comment) and the media kind (stik → media_type: 6 music video, 9 movie, 10 TV show). The encoder tag (©too) is shown but never changed, and anything else in the item list — cover art, lyrics, custom iTunes tags — is kept byte for byte.

Will this make YouTube Music index my video?

The tags make the file carry its title, artist, album and the music-video kind, which media players, Apple Music and ffmpeg all read, and YouTube pre-fills the title from the file. YouTube decides the category itself, though: set it to Music and add the song credits on the upload page, because that is what YouTube Music lists by.

Does it change the whole file?

The content changes only where it has to. If the index sits at the end of the file — the usual layout for camera recordings, ffmpeg's default output and the exports of the video editor — only the tail is different afterwards. If the index sits at the front (a fast-start file), the new tags go in place when they fit, and otherwise the media is moved once, with chunk offsets patched and spare room left so later edits fit in place. The tool says which case applies before you save. The browser still writes the whole file again either way, because the File System Access API works in a swap file that replaces the original; the progress panel sizes its estimate from that.

Which browsers can save into the file itself?

Chrome and Edge, through the File System Access API: pick the file with the chooser or drop it onto the page, and the save writes into that file, then reads it back to verify the tags. Safari and Firefox cannot write into a chosen file, so they download a tagged copy instead; its progress shows in the download manager, not on the page.

How long does a big file take, and how good is the estimate?

Two passes over the file: the copy, at the write speed of your disk, then Chrome's read-back check, at its read speed. The first save on a machine estimates from default guesses of 400 MB/s for both; after that the copy rate comes from your last save and the close rate from the newest save or video export on this machine, and the copy rate is re-measured within the first second of the copy. The panel shows elapsed, remaining, the expected finish time, bytes written and the current speed, and lists each stage with its estimate and what it rests on.

What about fragmented MP4s?

A fragmented file (moof boxes, as produced by streaming encoders) has its index at the front and its media cannot be moved, so the tags are written in place when they fit the existing room and the tool refuses otherwise, rather than writing a broken file.