Separate the container from the video codec
A container packages tracks, timing, metadata, and indexes. A codec defines how a video track is compressed and decoded. Renaming an HEVC file from .mov to .mp4 does not turn it into H.264, just as changing a ZIP filename does not convert the files inside it.
MP4 commonly carries H.264, HEVC, or AV1 video. WebM commonly carries VP8, VP9, or AV1. MOV, MKV, and AVI can contain many combinations. The current MDN video codec guide lists common codec and container relationships, but actual playback can still vary with profile, bit depth, hardware, licensing, and browser release.
This is why an extension list can only describe likely inputs. A browser-readable MP4/H.264 file is a conservative first test; no honest browser tool can guarantee that every file sharing an extension will decode.
Use a diagnostic ladder instead of random retries
- Test ordinary playback. Open the file directly in the same browser. If it cannot play, frame extraction cannot make the decoder support it.
- Try a known-good local file. A short H.264 MP4 or common WebM sample separates a site-wide problem from a source-specific one.
- Test another current browser on the same device. Different browsers may use different decoder paths even on one operating system.
- Test another device or operating system. This is especially useful for HEVC and newer profiles with uneven hardware or platform support.
- Inspect the stream metadata. A local media inspector can reveal codec name, profile, level, pixel format, bit depth, dimensions, frame-rate mode, and duration.
- Create a compatible derivative. Transcode only a copy with a trusted local tool, then keep the original as the source of record.
Recognize common failure patterns
The browser says the format is unsupported
The container or primary video track may not have a decoder available. A high-bit-depth, unusual chroma format, advanced profile, or codec licensing boundary can matter even when the codec family appears supported.
Playback works but seeking is unreliable
The file may have sparse keyframes, incomplete indexes, unusual timestamps, or damaged metadata. Forward playback can succeed because it decodes sequentially while random access depends on timing and index information.
The first frames work and later frames fail
A damaged segment, discontinuous timestamps, memory pressure, or a decode error later in the stream may be responsible. Try a shorter range around the failure and compare behavior in another player.
Audio plays but no picture appears
Containers carry separate tracks. The browser may support the audio codec while lacking support for the video codec or its profile.
Remote URLs add network rules to media rules
A direct URL must point to media that the browser can fetch and decode. A sharing page, cloud preview page, authenticated download, or HTML response is not a direct video file. The remote server also needs to permit cross-origin use when the tool draws the video to a canvas; otherwise browser security rules can block export even if playback appears possible.
Redirects, expiring signatures, missing byte-range support, hotlink protection, authentication cookies, and content-type mistakes can all make a remote source less reliable than a local file. Downloading a file you are authorized to use and selecting it locally removes most of those network variables.
When a remote URL is used, the browser contacts that third-party host directly. The host can receive normal request information such as IP address and browser headers. VideoToImg's privacy policy explains the boundary.
Choose a conservative compatibility target
For a derivative intended mainly for current browsers, H.264 video in an MP4 container remains a broadly compatible baseline. A common WebM combination is another useful target. Keep dimensions and frame rate appropriate for the actual task; converting a source to a larger resolution or higher frame rate does not create missing visual information.
For private footage, use a reputable local converter rather than uploading to an unknown service. Preserve the original separately, and document conversion settings when timing or visual fidelity matters. Re-encoding is lossy unless a lossless workflow is deliberately chosen, so a compatibility copy should not silently replace the source master.
The FFmpeg formats documentation is a primary reference for the demuxers and muxers supported by FFmpeg, but command options and codec availability depend on the installed build. This site does not run FFmpeg in the browser and does not claim equivalent format coverage.
Write a compatibility report that can be reproduced
Record the browser name and version, operating system, file extension, codec and profile when known, dimensions, duration, whether ordinary playback works, and the exact point where extraction fails. State whether the source was local or remote and whether a small known-good file worked in the same session.
Do not send a private source video merely to prove a bug. A short non-sensitive reproduction file or complete metadata is safer and often more useful. Remove personal filenames, signed URL parameters, and account identifiers from screenshots or logs.
Send reproducible reports to hello@videotoimg.com, or open the video to image converter to test a browser-readable local file.