Read every tag in your WebP.
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
An extended WebP keeps metadata in separate chunks: EXIF (camera,
date, GPS position), XMP (editor history and often a second copy of
the position), C2PA (a signed content credential, which is where
image generators write that a model made the picture) and ICCP (the
colour profile). OmniViewer reads every one, lists every tag in every directory,
and points each value at its own bytes in the hex pane.
Clear identifying, then download: the copy is rewritten without those chunks, the VP8X header that announced them is corrected, and the image data is copied byte for byte, so nothing is re-encoded. EXIF values can also be retyped in place. Everything happens in your browser.
It’s one lens on OmniViewer’s WebP Viewer — Convert, Frames & Quality: 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 WebP is decoded by your own browser and every conversion is encoded by it too. The clean copy is assembled from byte slices of your original file. Nothing leaves your computer.
Drop the file and open the CONVERT tab. Choose PNG for an exact copy with transparency kept, or JPG for a smaller file; the JPG quality starts near the quality the WebP was saved at, and transparent areas are filled with a colour you choose. Click Convert and the card shows the exact size of the result before you download it. An animated WebP converts the frame you picked on the FRAMES tab, or the whole animation to an animated PNG.
OmniViewer reads the bitstream and says. A lossy WebP stores a VP8 key frame (a "VP8 " chunk); a lossless one stores a VP8L bitstream. The info bar and the CONVERT tab name which one you have, whether it is a palette image, whether it has alpha and whether that alpha was itself stored lossily. An animated WebP can mix both, frame by frame, and STATS counts them.
A WebP does not store its quality setting; it stores the quantizers that setting produced. OmniViewer reads them from the VP8 frame header with a real boolean decoder, weights the four segment quantizers by how much of the image each covers, and inverts libwebp’s own quality curve. Measured against cwebp, it lands within one point of the -q used with noise shaping off and within two or three with it on, which is the default. Encoders that do not use libwebp’s curve read differently, so the number is shown as approximate.
Open the FRAMES tab. Step with the arrow keys, play with the space bar or drag the timeline; each frame is cut out of the file, decoded by your browser and composited with the blend and dispose rules the spec defines, so what you see is exactly what a browser shows at that moment. Save frame as PNG downloads the composited frame. To keep the whole animation, CONVERT turns it into an animated PNG with the same timings and loop count.
Yes. On the CONVERT tab, the GIF card writes every frame with its timing and loop count, each frame with its own 256-colour palette. GIF is limited to 256 colours per frame and on/off transparency, so a photographic animation loses detail and usually comes out bigger; if the destination plays animated PNG, the APNG card keeps every pixel and every level of transparency.
It can. An extended WebP may carry an EXIF chunk with the camera, the date and the GPS position, an XMP packet, and a C2PA content credential. METADATA shows them all and the info bar flags a GPS position as soon as the file opens. Clear identifying, or Download clean copy on the CHUNKS tab, writes a copy with those chunks removed and the VP8X header corrected; the image data is copied byte for byte, so nothing is re-encoded and no quality is lost.
Any WebP there is. The format itself stops at 4 GiB, because every RIFF size field is 32 bits, and at 16,383 pixels a side. OmniViewer reads the structure from the chunk headers alone, so opening a file costs a handful of small reads whatever its size, and an animation with tens of thousands of frames is indexed without decoding any of them. The preview and conversions are decoded by your browser, so their limit is its memory; the CHUNKS, METADATA, HEX and STATS tabs do not depend on that.
