Explore your MP4 boxes.
safe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQ
Drop an .mp4 and OmniViewer’s BOXES tab lays
out the ISO BMFF container as a tree: ftyp, moov,
mdat and every atom below them, each with its offset, size and a
plain-language description of what it holds. It reads box headers only — not the
media — so a huge file opens on a handful of tiny reads, locally.
This is also where you fix fast start: if the moov
index sits after the media, a one-click move puts it in front so the file streams
before it finishes downloading — pure byte surgery, no re-encoding, on files of
any size. The same drop also plays the video, edits metadata, reports stats, and
opens raw and hex views.
It’s one lens on OmniViewer’s MP4 File Viewer — GIF Export, Boxes & Metadata: drop a file and every tab is one click away. OmniViewer opens every file format, entirely in your browser — no upload, no server.
No. OmniViewer is a static page with no server-side processing: your MP4 is read directly by your browser and never leaves your computer. Even the fast-start fix and metadata edits happen locally, assembled from byte slices of your original file.
A tree of length-prefixed "boxes" (atoms): ftyp declares the format, moov is a small index holding every track’s codec, timing and byte offsets, and mdat is the actual compressed media. The player never scans mdat — it looks everything up in moov. MP4 is the ISO Base Media File Format, a descendant of Apple’s QuickTime .mov.
Because its moov index was written after the media data, a browser can’t learn the codecs or find any frame until the download reaches the end. That is the "fast start" problem. OmniViewer’s BOXES tab shows the verdict, and the Make streamable button moves moov to the front while patching every chunk offset.
No. The fix is pure byte surgery: the media bytes are copied untouched, only the moov index is rebuilt and the stco/co64 chunk-offset tables are patched to the new layout. Quality is bit-identical, and the rewrite streams — a 20 GB file is never held in memory.
Yes. The METADATA tab edits the iTunes-style tags (title, artist, album, date, genre and more) stored in moov/udta and downloads a re-tagged copy without re-encoding. It also shows the ©xyz GPS location atom, with a one-click Remove for a clean copy.
Yes — the GIF tab does it in the browser. Trim the clip on the scrubber, choose the frame rate, width, palette size, dither and loop count, and the tab encodes it locally with FFmpeg compiled to WebAssembly. There is no upload, no watermark and no account. Because the encoder holds the source in memory, the GIF tab caps the input video at about 512 MB — every other tab still opens a file of any size.
A GIF frame can use at most 256 colours. A converter that encodes straight from video falls back to a fixed, generic palette, which is what produces the muddy bands. OmniViewer runs FFmpeg’s two-pass recipe instead: palettegen measures the colours your clip actually contains, then paletteuse maps each frame onto that measured palette with the dither you picked.
Effectively unlimited. The box walk reads 16 bytes per box and skips the media data entirely, then parses only the small moov index — so a 20 GB movie costs a handful of tiny reads. Playback, raw and hex views read only the bytes needed on screen.
Yes. MOV, M4V and M4A use the same ISO BMFF container as MP4, so they get the same toolkit. OmniViewer identifies the format from the ftyp bytes, not the file extension, so a renamed file is detected for what it actually is.
Fragmented files — a skeleton moov followed by moof+mdat fragments — are detected and shown in the BOXES tree, but relocation rewrites are disabled: fragment offsets can’t survive a box shuffle, and such files are already built for streaming delivery.