Initializing... drag & drop files here
Supports: WEBP
cwebp command-line output. Batch conversion is supported.WebP is Google's web image format, announced in September 2010, built on the VP8 (lossy) and a custom predictor codec (lossless). Google's own figures put WebP lossy at 25-34% smaller than JPEG and lossless at 26% smaller than PNG — excellent for the web, but a poor fit for image-processing toolchains that want to read pixel values directly. PPM (Portable Pixmap), part of Jef Poskanzer's Pbmplus suite from 1988 and maintained as Netpbm since 1999, is the opposite design: a tiny ASCII header followed by raw RGB samples in scanline order. No DCT, no entropy coding, no color profile gymnastics — just pixels.
pnmscale, ppmtogif, pamcut, over 330 utilities total) are designed to be stacked with Unix pipes. Converting WebP to PPM lets you drop a modern web asset into a 1980s-style pipeline without writing a decoder.imread parses binary PPM (P6) natively for both 8-bit (CV_8U) and 16-bit (CV_16U) data. Many academic CV datasets ship as PPM precisely because parsing is trivial and reproducible across languages.pnmtopng, pnmtotiff, and Ghostscript, which makes it a clean intermediate for color-management and print-profile experiments.| Property | WebP (input) | PPM (output) |
|---|---|---|
| Developer | Google (2010) | Jef Poskanzer / Netpbm project (1988) |
| Magic number | RIFF...WEBP |
P6 (binary) or P3 (ASCII) |
| Compression | VP8 lossy or lossless predictor | None — raw RGB samples |
| Color depth | 8-bit RGB / RGBA | 8-bit (24 bpp) or 16-bit (48 bpp) |
| Alpha channel | Yes | No (use PAM / P7 for alpha) |
| Animation | Yes | No (single frame only) |
| Metadata (EXIF, ICC, XMP) | Yes | No (header is dimensions + maxval) |
| Typical 1 MP file size | 50-200 KB | ~3 MB (8-bit) / ~6 MB (16-bit) |
| Native browser display | Chrome, Firefox, Edge, Safari 14+ | None |
| Native CV/IP toolchain support | libwebp only | OpenCV, ImageMagick, GIMP, FFmpeg, Photoshop |
| Streaming via Unix pipe | Awkward | Designed for it |
| Magic | Format | Channels | Typical bit depth | When to pick it |
|---|---|---|---|---|
P6 |
Binary PPM | RGB | 8 or 16 bits per channel | Default for color images — fastest to parse, smallest of the PPM variants |
P3 |
ASCII PPM | RGB | 8 or 16 bits per channel | Human-readable / diff-able; ~3-5× larger than P6; OpenCV has historical issues parsing it |
P5 |
Binary PGM | Grayscale | 8 or 16 bits per channel | Single-channel scientific data, depth maps, masks |
P4 |
Binary PBM | 1-bit B&W | 1 bit per pixel | Bitmap masks, dithered output, print-press separations |
P7 (PAM) |
Binary PAM | RGBA / arbitrary | 1-32 bits per channel | When you need alpha or non-standard channel layouts |
xconvert emits P6 for 8-bit and 16-bit color, and P4 when Bit Depth is set to 1-bit.
PPM stores raw, uncompressed pixel data. A 1920×1080 8-bit RGB PPM is fixed at 1920 × 1080 × 3 = 6,220,800 bytes plus a ~20-byte header — roughly 6 MB. The same image as WebP is typically 100-400 KB because VP8/VP8L applies inter-block prediction and entropy coding. The size jump is the format working as designed; if file size matters more than parser simplicity, convert to PNG instead.
8-bit (Recommended) covers 99% of cases — it matches what WebP itself stores internally for standard SDR content and is what every common reader expects. Choose 16-bit only if your downstream tool (a scientific imaging pipeline, an HDR processing chain, a numpy.uint16 workflow) actually needs the extended range; otherwise the file doubles in size with no visible benefit. 1-bit produces a P4 PBM bitmap and is mainly useful for masks and dithered black-and-white output.
Yes for the binary P6 output that xconvert emits — OpenCV documents native support for .pbm, .pgm, .ppm, .pxm, and .pnm, and imread detects format from the magic number, not the extension. Both 8-bit (CV_8U) and 16-bit (CV_16U) PPM decode correctly. Note: OpenCV has historical edge-case bugs with ASCII (P3) PPM, but xconvert emits P6 by default so this isn't a concern here.
PPM has no alpha channel — the format pre-dates RGBA by years. Transparent pixels are flattened against an opaque background during conversion. If you need to preserve transparency, either output PNG (which fully supports alpha) or use a PAM (P7) toolchain manually with pamx from the Netpbm suite.
pnmscale | ppmtogif?Yes — that's exactly the use case PPM was designed for. pnmscale -xysize 800 600 input.ppm | pnmtopng > output.png and similar pipelines work directly on xconvert's output. The Netpbm package documents over 330 such building blocks covering geometry, color, dithering, and format conversions.
No. The PPM header carries only the magic number, width, height, and maxval. Any EXIF (camera info, orientation, GPS) and ICC color profiles in the source WebP are stripped during conversion because PPM has no slot for them. If you need metadata to survive the round trip, keep a copy of the original WebP or use TIFF as the intermediate format instead.
Most desktop OSes don't ship a PPM viewer. GIMP opens PPM directly on Windows, macOS, and Linux; IrfanView handles it on Windows; ImageMagick's display works anywhere ImageMagick is installed. On macOS the simplest path is to convert back with pnmtopng input.ppm > output.png or use xconvert's reverse direction — see PPM to PNG or PPM to JPG.
Single frames only. Animated WebP files are decoded to the first frame and emitted as a single PPM. PPM has no notion of animation; if you need every frame, the typical approach is to use ffmpeg -i input.webp -f image2 frame_%04d.ppm locally, since xconvert's browser-side pipeline focuses on still images.
Files process in your browser session for this conversion — they aren't uploaded to a remote server, which keeps medical imaging, internal datasets, and pre-publication research images private. There is no sign-up, no watermark, and no file-count limit beyond what your local RAM can hold (PPM files are large; very high-resolution batches benefit from a desktop browser with plenty of free memory).