Initializing... drag & drop files here
Supports: PPM
PPM (Portable Pixmap) belongs to the Netpbm family designed by Jef Poskanzer in 1988 so images could pass through email and Unix pipes without corruption. The header is plain ASCII — magic number (P6 for binary, P3 for plain), width, height, maxval — followed by raw RGB samples with no internal compression of any kind. That simplicity makes PPM excellent as an intermediate format and terrible as a storage format: the spec itself calls the layout "egregiously inefficient" and "highly redundant."
convert and Netpbm utilities such as pamscale and pnmtopng produce PPMs that are easy to inspect with xxd but oversize for Slack, email, or peer review. Resampling to 720p drops the file to ~2.76 MB without losing the pipeline-readable format.For long-term storage, the Netpbm documentation itself recommends converting to PNG — same lossless quality, typically 40-70% smaller because PNG applies DEFLATE plus filter prediction. For photos meant for the web, JPEG yields 25-50x reductions at visually identical quality. Use TIFF if you need lossless plus metadata, or WebP for modern web delivery. If you only need a smaller PPM (not a new format), Resize PPM is the dedicated resampler.
| Property | PPM (P6) | PNG | JPEG | TIFF | BMP |
|---|---|---|---|---|---|
| Internal compression | None | DEFLATE (lossless) | DCT (lossy) | LZW / DEFLATE / none | None (usually) |
| Lossless | Yes (raw) | Yes | No | Yes (with LZW/Deflate) | Yes |
| Typical 1920x1080 8-bit | ~6.22 MB | ~2-5 MB | ~150-400 KB | ~6-12 MB | ~6.22 MB |
| Bit depth | 1-16 per channel (maxval ≤ 65535) | 1, 2, 4, 8, 16 | 8 (12 in rare variants) | 1-32 | 1, 4, 8, 16, 24, 32 |
| Alpha channel | No (use PAM for alpha) | Yes | No (use JPEG-XL/HEIF) | Yes | Yes (BMPv5) |
| Metadata (EXIF/XMP) | None | tEXt/iTXt chunks | EXIF/XMP | Full EXIF/IPTC/XMP | None |
| Created | 1988 (Jef Poskanzer) | 1996 (W3C) | 1992 (JPEG WG) | 1986 (Aldus) | 1990 (Microsoft) |
| Best use | Pipeline intermediate, CV/research | Lossless web/archive | Photos for sharing | Print, archival masters | Windows legacy |
| You want to... | Pick this setting | Result for a 6.22 MB 1080p PPM |
|---|---|---|
| Fastest size reduction with one click | Quality Preset = Medium | ~2.8 MB (resampled to ~70%) |
| Hit an exact attachment cap | Specific file size = 2 MB + Smart Scaling | ~1.95-2.0 MB |
| Fine-tune perceived quality | Image Quality slider at 60 | ~2.0-2.5 MB |
| Halve dimensions, keep 8-bit | Resolution Percentage = 50 | ~1.55 MB |
| Drop precision, keep dimensions | Bit Depth = 8-bit (from 16-bit) | ~6.22 MB (was ~12.44 MB) |
| Binary mask only | Bit Depth = 1-bit | ~260 KB |
| Targeted at thumbnail use | Preset Resolution = 360p | ~700 KB |
PPM has no internal compression at all. The Netpbm spec explicitly calls the layout "egregiously inefficient." A 1920x1080 8-bit PPM is exactly width x height x 3 bytes (~6.22 MB) plus a tiny ASCII header. The same image as PNG runs DEFLATE over filtered scanlines and usually lands at 2-5 MB. If your goal is a small lossless file, converting to PNG is almost always better than compressing the PPM in place.
Yes — "compressing" a PPM means changing what is encoded, not how it is encoded. The tool resamples the raster (lower resolution, lower bit depth, or both) and writes a new, smaller P6 PPM. Because the result is still raw RGB, it loads in any Netpbm/ImageMagick/OpenCV pipeline without modification. If you want true compression, convert to PNG or JPEG instead.
Keep 16-bit only if downstream code consumes more than 8 bits per channel — for example HDR tone-mapping, photometric analysis, medical imaging, or scientific sensor data. Most ImageMagick, OpenCV, and GIMP workflows treat the output as 8-bit anyway, so dropping to 8-bit halves the file size with no visible difference. The Netpbm docs note that 16-bit PPM (maxval > 255) support is comparatively rare across applications.
Both use the same header layout. P3 stores each sample as ASCII decimal digits separated by whitespace, so a single byte per channel becomes 4-5 characters on disk — typically 3-5x larger than P6. P6 stores samples as raw bytes (or two bytes each at 16-bit). This tool reads either variant on upload and writes P6 on output for the smallest size. The Netpbm documentation notes P3 is "fairly rare" today.
No. PPM is strictly RGB. The Netpbm family handles alpha through PAM (P7), a sibling format. If you need alpha, convert to PNG, TIFF, or WebP — those preserve a transparent channel that PPM cannot represent.
Yes — drop the whole set into the upload zone in one go. Each file is processed independently with the same settings, which matches the typical use case of resizing or quantizing a frame sequence. For very large dumps (thousands of frames or many GB total), the local Netpbm command line (pnmscale or pamscale piped through pnmtopng) is faster because there is no upload.
Only if you change the bit depth. Picking 8-bit forces maxval = 255 in the output header; 16-bit yields maxval = 65535; 1-bit produces a PBM-style binary (technically magic number P4, returned with a .ppm extension on request). Resolution-only changes preserve the original maxval.
For a photo at 1920x1080, dropping to 720x405 at 8-bit (Quality = Medium, Resolution Percentage = 38) yields a ~875 KB PPM that still loads in every PPM-aware tool. Below that, artifacts from heavy downsampling start to dominate. If you need to go smaller, the right answer is a format change to PNG or JPEG rather than further PPM resampling.
Files are uploaded to xconvert's processing servers, converted, and deleted shortly after download. Nothing is stored long-term, nothing is shared, no watermark is applied, and no account is required.