How to convert video to high-quality animated webp
- Step 1Start from the cleanest source you have — Quality output starts with quality input. Convert from your master or highest-bitrate export, not from a clip that's already been compressed twice — re-compressing artefacts can't be undone. If the source is already a low-quality WebP/GIF, the best you'll get is preserving its existing quality.
- Step 2Encode at native (display) width, no upscaling — Set Width to the source's native width (or your target display width) — up to 1920. Lanczos keeps downscales crisp, but upscaling past the source resolution invents soft pixels and adds nothing. For fidelity, match or downscale, never upscale.
- Step 3Keep FPS at or near the source — For smoothness fidelity, set FPS close to the source (24–30 for typical footage; up to 60 for high-frame-rate sources). Dropping FPS saves bytes but is a quality trade-off — for a 'no visible loss' goal, keep it high.
- Step 4Set Quality to 90–100 — For visually-indistinguishable output, set Quality to 90–95 (often perceptually identical to 100 at far smaller size) or 100 for the top of the lossy dial. Remember: 100 is high-quality lossy, not bit-exact lossless — that mode isn't exposed.
- Step 5Run and A/B against the source — Click Run; the looping
.webpdownloads. Open it side-by-side with the source clip at 100% zoom on the most detailed frame — gradients, text, fine texture. If you can't tell them apart, you're done; if you can, raise quality or width. - Step 6Trade size only where it's invisible — If the file is heavier than you'd like, drop FPS before quality (motion smoothness is less noticed than per-frame fidelity on detailed loops), or trim duration with lossless-trimmer. Lowering quality below 90 is where visible loss starts.
How the quality dial behaves
Practical guidance for the 1–100 -q:v quality value. All of it is lossy VP8; higher = closer to the source and larger.
| Quality | Perceived fidelity | Use for |
|---|---|---|
| 100 | Top of the lossy dial — indistinguishable on virtually all footage (but NOT bit-exact) | Maximum fidelity when size is secondary |
| 90–95 | Visually indistinguishable on nearly all content; far smaller than 100 | The recommended 'no visible loss' setting |
| 80 (default) | Excellent for web; faint loss only on extreme detail/text | General-purpose loops |
| 60–70 | Noticeable on edges and gradients | Chat-grade, size-first loops (not for fidelity) |
| < 50 | Visible blocking and banding | Avoid for any quality-sensitive use |
Lossy (this tool) vs true lossless WebP vs source video
What 'quality' really means here, so you pick the right format for your fidelity need.
| Target | Fidelity | Available here? |
|---|---|---|
| High-quality lossy WebP (q 90–100) | Visually indistinguishable, not bit-exact | Yes — this tool |
libwebp -lossless 1 | Mathematically pixel-exact, much larger | No — not exposed in the UI |
| Keep as video (H.264/H.265) | Codec-dependent; can be visually lossless at high bitrate, plus audio | Use video-transcoder |
| Per-frame PNG export | Truly lossless still frames (no loop) | Use thumbnail-extractor (PNG) |
Cookbook
High-fidelity conversions and the A/B reasoning behind the settings. Always compare against the source at 100% on the most detailed frame.
Brand loop at quality 95, native width
A product/brand loop where fidelity matters. Quality 95 at the source's native width is visually identical to the master while staying well under the GIF size.
Source: brand-loop.mov (3.0s, 1080×1080) Controls: FPS 30 · Width 1080 · Quality 95 FFmpeg (libwebp): -vf fps=30,scale=1080:-1:flags=lanczos -loop 0 -q:v 95 -an → brand.webp 1080×1080, looping ~1.8 MB A/B at 100% zoom: indistinguishable from source. Equivalent GIF was 3.1 MB and visibly dithered.
95 vs 100 — almost no visible gain, real size cost
On most footage, quality 95 is perceptually identical to 100 but meaningfully smaller. Spend the bytes only if you can actually see a difference.
Source: detail.mp4 (2.5s, 720px) Quality 100 → 1.6 MB Quality 95 → 1.1 MB (no visible difference at 100%) Quality 90 → 0.85 MB (faint loss only on extreme detail) Default to 95 for 'no visible loss'; reserve 100 for archival.
Downscale cleanly with Lanczos
A 4K master converted down to 1280px. Lanczos scaling keeps edges crisp — downscaling well is part of perceived quality.
Source: master-4k.mov (3840×2160) Controls: FPS 24 · Width 1280 · Quality 92 scale=1280:-1:flags=lanczos → sharp downscale → crisp 1280×720 WebP, no resampling mush Never set Width above the source width — upscaling adds soft pixels and bytes, not detail.
Keep FPS high for motion fidelity
A high-frame-rate sports clip. To preserve motion smoothness, match the source FPS rather than halving it.
Source: action-60fps.mp4 (2.0s, 60fps) FPS 60 · q90 → smooth motion, ~2.4 MB FPS 30 · q90 → choppier on fast pans, ~1.3 MB For a fidelity goal, keep FPS high. Drop it only when the size constraint outweighs motion smoothness.
When you truly need pixel-exact — don't use WebP
A use-case that needs bit-exact frames (e.g. a technical diagram animation). Lossy WebP isn't it, and lossless mode isn't exposed. Use a still-frame PNG export or keep it as video.
Need: pixel-exact frames - This tool: lossy only (even q100 isn't bit-exact) - Per-frame PNG: thumbnail-extractor (format=png) → lossless stills - Keep as video: video-transcoder (H.265, low CRF) → visually lossless + audio Pick by whether you need a loop, stills, or a clip with sound.
Edge cases and what actually happens
Expecting true lossless from quality 100
Lossy onlyQuality 100 is the top of libwebp's lossy -q:v dial, not the separate -lossless 1 mode (which isn't exposed). It's visually indistinguishable on virtually all footage but not mathematically pixel-exact. If you genuinely need bit-exact frames, export per-frame PNGs with thumbnail-extractor or keep the clip as video.
Output still shows visible loss at high quality
Check the sourceIf quality 95 still looks degraded, the source was probably already compressed — you can't recover detail that isn't there, and re-encoding may even add a generation of loss. Start from the master or a higher-bitrate export. Heavily-compressed phone footage at low light is the usual culprit.
Upscaling to chase 'more quality'
No benefitSetting Width above the source resolution invents soft pixels and inflates the file without adding real detail. Lanczos can't reconstruct information that isn't in the source. For fidelity, match the native width or downscale — never upscale.
Audio quality matters to you
Not applicableWebP carries no audio (the encoder uses -an), so there's no audio-fidelity setting — the track is dropped entirely. If audio fidelity is part of your 'quality' goal, WebP is the wrong format; keep the clip as a video via video-transcoder.
High-quality long loop becomes huge
Trim or drop FPSQuality 95 at native width and FPS 30 over many seconds produces a large file — bytes scale with frames × quality × area. For a fidelity goal, trim to the essential seconds with lossless-trimmer first; that loses no per-frame quality, only duration.
Banding appears in a smooth gradient
Raise qualityFaint banding in a smooth sky/gradient at quality 80 is the lossy codec quantising subtly. Raise quality to 90–95 to clear it — WebP still beats GIF here, which dithers gradients by design. If banding persists at 95, the source gradient may already be 8-bit limited.
Fine text or thin lines soften
Raise quality / widthLossy compression hits high-frequency detail (text, hairlines) first. For loops containing captions or UI text, push quality to 92–100 and ensure Width matches display size. If text is central to the loop, consider keeping it as video where the codec handles text better at a given size.
File exceeds your tier's size limit
413 tier limitGating is by source file size, not duration: Free 1 GB / 1 file; Pro 10 GB / 5 files; Pro-media 100 GB / 50 files; Developer 100 GB / unlimited. High-quality masters can be large — resize the source with video-resizer or trim it before converting if you hit the cap.
Frequently asked questions
Is the output really lossless?
No — and we won't pretend otherwise. This is high-quality lossy WebP via libwebp's -q:v dial (1–100). At 90–100 it's visually indistinguishable from the source for almost any footage, but it is not libwebp's separate -lossless 1 (bit-exact) mode, which isn't exposed in the UI. For a short loop the difference is essentially never visible.
What quality should I use for 'no visible loss'?
90–95. On nearly all content, 95 is perceptually identical to 100 at a meaningfully smaller size, so it's the recommended fidelity setting. Reserve 100 for archival masters where you don't care about bytes. Below 90 is where loss starts to show on extreme detail.
How can I make it pixel-exact if I really need that?
Not with animated WebP here — the lossless mode isn't exposed. If you need bit-exact frames, export per-frame PNGs with thumbnail-extractor (PNG is lossless), or keep the content as a video at high bitrate / low CRF via video-transcoder. Choose by whether you need stills, a loop, or audio.
Will it look better than GIF at high quality?
Yes, clearly. GIF is locked to 256 colours and dithers gradients no matter what; WebP at quality 90–95 keeps full 16.7-million-colour fidelity with clean gradients and sharp edges — and it's still smaller. There's no fidelity scenario where GIF beats high-quality WebP on photographic content.
Does encoding at higher quality lose anything compared to the source?
At 90–100, nothing you can see on a short loop. There's always some lossy quantisation in principle, but it's below the visible threshold for typical footage at those settings. The bigger fidelity risk is starting from an already-compressed source — fidelity can't exceed the input.
Should I match the source FPS for quality?
For motion fidelity, yes — keep FPS at or near the source (24–30 typical, up to 60 for high-frame-rate clips). Dropping FPS saves bytes but trades motion smoothness, which matters on fast pans. For a 'no visible loss' goal, keep FPS high.
Can I set the height to keep the exact resolution?
You set Width; height auto-locks to the source aspect (scale=W:-1:flags=lanczos), so the proportions are always exact. To preserve native resolution, set Width to the source width — don't go above it, as upscaling only softens and bloats.
Is my master footage uploaded?
No. Encoding runs entirely in your browser via FFmpeg.wasm, so high-value master footage never reaches a server. Only an anonymous processed-file counter is recorded if you're signed in — never the content.
Why does my high-quality WebP still look soft?
Most often the source was already compressed (you can't recover lost detail), or you upscaled past the source resolution. Start from the master, encode at native width or below, and use quality 90+. If it's a low-light phone clip, the noise itself eats quality at any setting.
What's the largest source I can convert?
Gating is by file size, not duration: Free 1 GB / 1 file; Pro 10 GB / 5 files; Pro-media 100 GB / 50 files; Developer 100 GB / unlimited. High-quality masters can be big — trim with lossless-trimmer or resize first if you hit your tier cap.
Does quality 100 keep my audio?
No — WebP has no audio channel at any quality, and the encoder strips it with -an. Quality only affects the visual frames. If audio is part of your quality requirement, keep the clip as a video instead.
How do I verify there's no visible loss?
Open the output WebP and the source clip side-by-side at 100% zoom and compare the most detailed frame — gradients, text, fine texture. If you can't tell them apart, you're at no-visible-loss. If you can, raise quality (toward 95–100) or width to the source's native resolution.
Privacy first
Every JAD Video tool runs entirely in your browser via WebCodecs and FFmpeg (WebAssembly). Your video files never leave your device — verified by zero outbound network requests during processing.