Plan access
Free supports one video and up to 12 images by count or manual capture, including first/last frame shortcuts, with JPG and PNG exports. Pro queues, assisted review, WebP, contact sheets, frame boards and presets are currently available with site-provided samples only. Purchases and own-video Pro access are not open. Existing projects and drafts can be recovered and exported. Compare Free and Pro.
Input formats
| Input family | Release scope | What to expect |
|---|---|---|
| MP4 with H.264 / AVC | Priority target | A practical starting format. Codec profile, bit depth, and browser support still matter. |
| WebM with VP8 / VP9 | Priority target | Requires a compatible browser decoder. |
| MOV | Codec-dependent | MOV is a container. HEVC or professional codecs inside it may not decode. |
| HEVC / H.265 | Browser and OS dependent | No universal support promise. Make an H.264 MP4 copy when needed. |
| AV1, 10-bit, HDR, wide gamut | Advanced / variable | Decode and color conversion vary. Validate a short export before relying on it. |
| DRM-protected, damaged, or unsupported media | Outside release scope | No protection bypass, file repair, or server conversion fallback. |
Browser requirements
Use a current desktop or mobile browser with JavaScript enabled. The preferred media path uses the browser’s video decoder through WebCodecs. A player-based fallback may work for some files but provides less precise positioning; the workspace indicates fallback behavior.
The initial target matrix is Windows Chrome and Edge, macOS Chrome and Safari, iPhone Safari, and Android Chrome. Device-specific validation remains necessary. Try a short sample before starting a large task.
Earlier verification notes and release coverage
What has been checked
Automated checks cover media sampling, resource ownership, naming, presets, project validation, metadata-only local draft storage and backup, cancellation, and conflicting updates. Interactive Chromium checks include H.264 MP4 samples at 24 FPS, 60 FPS, variable frame rate, and a short two-frame clip. Browser checks below are scoped to the tested files and operations.
| Area | Completed coverage |
|---|---|
| Core workflows | Count and interval sampling; single, first, and last frame capture; JPG, PNG, and WebP; ZIP with JSON manifest; a 20-image contact sheet; cancellation and retry; invalid input. |
| Playback fallback | WebCodecs disabled to simulate fallback. PNG output from the two-frame clip showed the expected FRAME 002 picture. |
| Projects and local drafts | Three-source/18-image reviews; full and partial restoration, batch matching, scene representatives and selected images; refresh recovery, deletion and conflicting updates in separate tabs. Local drafts contain metadata only; original videos must be selected again. |
| Safari local recovery and backup | macOS Safari processed two H.264 samples into 24 candidate images. Reopening, downloading a saved draft without videos, selecting originals again, and rebuilding the full review were checked. Before/after project metadata matched except the save time. This is sample-specific coverage. |
| Local stress fixtures | Chromium checked a 25-minute 480 × 270 H.264 sample and a 6-second sample padded to 256 MiB with a valid container padding box. Four frames per video and eight PNG exports were verified. This exercises duration, seeking, full file hashing and metadata backup; it is not a high-resolution or high-bitrate performance benchmark. |
| Selected frame boards | Local Chromium exported 11 selected images from three videos as PNG and JPG, grouped by video or existing scenes. A separate 36-image board included a rotated portrait source without stretching. A 156-image queue checked cancellation, keeping the previous preview and selections. Stale downloads, invalid layouts and output limits were checked. The single-video 20-image contact sheet was rechecked after sharing the drawing code. |
| Responsive layout | Desktop-width and narrow 390 px / 319 px viewports. A narrow viewport is not a physical mobile-device test. |
Safari coverage is limited to the local checks above. Edge and actual iPhone/Android device tests have not yet been completed. These checks do not establish support for every codec, large file, or device.
Saved board layout recovery
Earlier board layout recovery verification passed 265 automated checks and TypeScript checking. The automated coverage includes version 2 board layout metadata, version 1 project and draft compatibility, metadata-only backup storage and layout change tracking. Local Chromium restored three sources and 11 selections with the saved layout, checked legacy defaults, invalid input protection, edit/revert tracking and oversized-layout metadata saves, then downloaded PNG and JPG boards. macOS Safari restored all six layout settings, refreshed and reopened the saved draft after relinking, then regenerated and downloaded JPG. Both workflows required explicit board recreation. Narrow Chromium viewports at 390px and 319px showed no horizontal overflow. These are sample checks; Edge, physical mobile devices and broader codec combinations remain unverified for this update.
A valid saved layout can be restored even when its output exceeds this device’s rendering limits. The layout remains editable and can still be saved. Reduce columns, image width or selected image count before creating the board. Original videos must be reconnected to restore the review, and board previews must be created again. No video or image cache is used.
Reusable board layouts
Saved board layouts keeps up to 20 metadata presets in a separate browser-and-site collection. Each reuses five values: grouping, columns, image width, timestamp visibility and PNG or JPG format. Applying one keeps the current title, queue, review choices, extraction settings and naming. Saving, updating, renaming, deleting or transferring presets does not apply them or change the current project metadata.
JSON layout backups have their own format and a 100 KiB UTF-8 limit. All entries must validate before a selectable import preview is shown. Imports can skip matching names or save copies with new names, and commit the chosen additions together or keep the prior collection intact. Browser storage must be available to save presets; blocked, corrupt or full storage reports an error. The collection contains no videos, images, board previews, project titles or review state.
Applied values continue to use the existing version 2 project and draft metadata; no preset ID or collection is embedded. Version 1 and version 2 project/draft recovery and existing extraction preset formats are retained. Preset validation does not increase canvas or device limits: a valid layout may need smaller dimensions or fewer selected images before rendering. Original videos are still required to rebuild image previews. The completed checks above describe their original release scope.
Earlier reusable-layout verification passed 284 automated tests, TypeScript checking and the production build. Real Chromium and macOS Safari checks covered saving and renaming layouts, applying across projects, JSON backups, imports that skipped matching names or saved renamed copies, and refresh persistence. Chromium also checked cancelling and confirming updates/deletions, selected-subset exports, and malformed, unsupported or over-100-KiB backup rejection. Existing extraction preset application and backup import previews continued to work.
A three-video Project B kept its title, all 18 candidates, nine selections, extraction settings and naming; only the five applied board values changed. Non-applying management and transfers left project metadata unchanged. The earlier saved draft downloaded before and after these operations was byte-identical at 5,447 bytes. A downloaded PNG contained the expected nine images at 792 × 1,145 px. English interface/demo content and no horizontal overflow were checked in Chromium at 390 px and 319 px. These are local sample checks, not physical-mobile testing or a guarantee for other codecs and devices. These checks were completed locally before publication.
Device safeguards
Free has a separate 12-image limit. The values below are device safeguards used by larger Pro sample tasks and existing-work recovery.
| Guardrail | Desktop | Mobile |
|---|---|---|
| Source file limit | Up to 1 GB | Up to 200 MB |
| Frames per batch | 500 | 100 |
| ZIP image data budget | 500 MB | 100 MB |
| Selected images per frame board | 500 total | 100 total |
| Contact sheet and frame board pixel budget | 16 megapixels | 4 megapixels |
| Contact sheet and frame board side length | 8,192 px maximum | 8,192 px maximum |
A device can run out of resources below these values. Video resolution, codec complexity, concurrent tabs, and output format all affect memory use. A decoded 4K picture is much larger than its compressed source frame.
Timing, color, and export
Time-based sampling selects decoded pictures near requested timestamps. It is not a promise to export every source frame. On the Mediabunny path, the tool records decoded presentation timestamps, including for variable-frame-rate videos. In compatible preview mode, timestamps are approximate browser seek times and true last-frame extraction is unavailable. The 0.1-second navigation buttons move in time; they are not indexed previous/next-frame buttons.
JPG and PNG are standard export paths. WebP export requires browser encoding support; the tool shows an error if it is unavailable. Original-size exports preserve decoded display dimensions; browser color conversion means they are not a guaranteed pixel-identical archival copy, particularly with HDR material.
Contact sheets and selected frame boards preserve the image aspect ratio. Frame boards place each image inside a 16:9 tile without cropping or stretching. Their final size is limited to 8,192 pixels on either side and 16 megapixels on desktop, or 4 megapixels on mobile. Both checks apply; staying under one does not bypass the other. ZIP output is created locally and still requires memory and download support from your browser.
If a video fails
- Confirm it plays in a trusted local player and is fully downloaded.
- Try a short section in a current desktop browser.
- Reduce frame count, image dimensions, or export size if the task runs out of resources.
- For an unsupported codec, make a local H.264 MP4 compatibility copy or use a desktop extraction workflow.
Read the MOV and iPhone troubleshooting guide or the browser and FFmpeg comparison for more detail.