Initializing... drag & drop files here
Supports: MJPEG
This is the question almost everyone arriving here is really asking, and the answer is definite: converting MJPEG to WebP on this page produces a still image, not an animated one. WebP as a format supports animation, but this conversion decodes the frame you select and saves it as a single static picture; ask for several frames and you get several separate .webp files, not one animated file. If you want the motion preserved, Motion JPEG has two animated targets on this site and they are one click away. The comparison below shows exactly what each route gives you so you can pick once and be right.
| Target | Moving or still? | Compression | Alpha | Best for |
|---|---|---|---|---|
| WebP (this page) | Still — one file per selected frame | Lossy by default, lossless available | Supported by the format; MJPEG sources carry none | Web thumbnails, page assets, anything size-sensitive |
| JPG | Still | Lossy only | No | Maximum compatibility; every tool on earth reads it |
| PNG | Still | Lossless at the Highest preset | Yes | Evidence stills, editing masters, screenshots with text |
| TIFF | Still | Lossless with LZW or Deflate | Depends on compression choice | Archives, print, scientific and forensic workflows |
| GIF | Animated | Lossy — 256-colour palette | 1-bit only | Short loops that must play everywhere, including old email clients |
| APNG | Animated | Lossless per frame | Full 8-bit | Short loops where colour fidelity matters more than file size |
| MP4 | Video | Modern inter-frame coding | No | Anything longer than a few seconds — far smaller than any animated image |
.mjpeg extension, so rename a .mjpg first; the actual container is then identified from the file's bytes, so an AVI or QuickTime file carrying Motion JPEG that has been renamed is handled correctly too.| Lossless? = No (default) | Lossless? = Yes | |
|---|---|---|
| Pixel fidelity | Every quality preset alters some pixels | Bit-exact copy of the decoded frame |
| Effect of Quality Preset | Controls the trade-off; lower preset, smaller file | Ignored — there is no quality to trade |
| Typical size vs a PNG of the same frame | Far smaller | Still smaller than the PNG, per Google's own measurements |
| Good for | Thumbnails, galleries, page assets, previews | Evidence frames, before-and-after comparisons, anything to be re-edited |
| Worth knowing | The frame was already JPEG-compressed in the camera, so this is a second lossy generation | Preserves the decoded frame exactly, but cannot undo the camera's original JPEG loss |
Not from this conversion. Each selected frame is decoded and written as its own still .webp; choosing Multiple Screenshots produces a numbered set of separate files rather than one animated file. WebP itself supports animation, so this is a property of how this conversion is built, not a limitation of the format. For a moving result use MJPEG to GIF or MJPEG to APNG, both of which genuinely animate, or MJPEG to MP4 for anything beyond a few seconds.
Yes, and we checked rather than assumed. We extracted a frame from a raw Motion JPEG stream and ran it through the WebP encoder both ways: with Lossless? set to Yes the output matched the extracted frame with zero differing pixels, and it was still smaller than a PNG of the same frame. With the default No, every quality preset we tried altered some pixels. One caveat worth being clear about — "lossless" here means lossless relative to the frame as decoded, which the camera had already compressed as a JPEG.
Because for the overwhelming majority of WebP conversions the point is a small file, and lossy WebP is dramatically smaller. Google's own figures put lossy WebP around 30% smaller than comparable JPEG. On a frame that came out of a camera as a JPEG in the first place, that extra generation of loss is usually invisible at normal viewing sizes. Switch it to Yes when the frame is going to be examined closely, enhanced, or presented as a record.
Usually, yes — that is the format's entire reason for existing, and Google measures roughly 30% better compression than JPEG at comparable quality. Whether it is worth it depends on the destination. For a web page, WebP is the better choice on every current browser. For an email attachment, a case file, or a hand-off to someone whose software you do not control, the size saving rarely justifies the compatibility risk and MJPEG to JPG is the safer answer.
Because a raw .mjpeg file is just concatenated JPEG images with no timestamps, no duration and no declared frame rate — there is nothing for a timestamp to point at. Seeking to a non-zero time on such a stream returns no frames, so no file is written. Leave Time at 0 for the first frame, or use Multiple Screenshots, which walks the decoded stream in order rather than seeking, and works reliably. If your file is really a renamed AVI or MOV, convert it from that container and Time will work normally.
As many as the Capture Rate produces across the clip. Rates run from one frame every 0.1 seconds up to one every 10 seconds, and every interval yields a separate .webp. Since a raw Motion JPEG stream carries no rate of its own, decoders assume a nominal frame rate, so the number of files you get reflects that assumption rather than the camera's real capture speed — a stream of 100 frames yields four files at "1 second per frame".
WebP supports a full 8-bit alpha channel, so transparency is preserved when a source has it. Motion JPEG sources do not: JPEG has no alpha channel at all, so every frame is fully opaque before it reaches the encoder. If you need a transparent background you will have to cut it yourself in an image editor after conversion — no converter can invent alpha that was never recorded.
It is uploaded over an encrypted connection, converted on our servers, and deleted automatically after a few hours. Nothing is shared, published or reused. There is no account requirement, no watermark on the output, and no cap on how many frames you extract from a clip.