Initializing... drag & drop files here
Supports: PNG
PNG (Portable Network Graphics, standardised as ISO/IEC 15948) is a great delivery format — it ships compressed, supports transparency, and decodes everywhere. PPM (Portable Pixmap), part of the Netpbm family that Jef Poskanzer first released as Pbmplus in 1988 and Bryan Henderson has maintained as Netpbm since 1993, is the opposite: a tiny ASCII or binary header followed by raw RGB samples. Converting PNG to PPM strips out compression, filtering, and chunk metadata so downstream code can work on plain pixels.
pnmscale, ppmtoarbtxt, ppmcie, and pamtopng are designed to read one PPM from stdin and write another to stdout, so PNGs first need to be converted (typically via pngtopnm or this page) before they enter the pipeline.printf per pixel; converting a reference PNG into PPM lets you diff your renderer's output byte-for-byte.| Property | PNG | PPM |
|---|---|---|
| Standard | ISO/IEC 15948 (2003), W3C Recommendation | Netpbm spec at netpbm.sourceforge.net (Poskanzer, 1988) |
| Compression | Lossless DEFLATE plus pre-filtering | None — raw RGB samples |
| File size (1920x1080 photo) | ~1-5 MB | ~6.2 MB binary (P6) / ~17-19 MB ASCII (P3) |
| Bit depth | 1, 2, 4, 8, 16 bits per channel | 1 to 16 bits per channel via maxval (typical 8 or 16) |
| Color model | sRGB by default; gAMA/cHRM chunks for others | RGB in ITU-R BT.709 with BT.709 gamma |
| Transparency | Yes (alpha or tRNS chunk) | No — use PAM if you need an alpha channel |
| Metadata | tEXt, iTXt, eXIf, ICC profile chunks | Comments only (lines beginning with #) |
| Programmatic parsing | Requires libpng or platform decoder | ~30 lines of C; trivial in any language |
| Browser support | Universal | None (no native browser viewer) |
| Variant | Magic | Body | Typical 1920x1080 size | When to pick it |
|---|---|---|---|---|
| Plain | P3 | ASCII decimals separated by whitespace | ~17-19 MB | Diff in a text editor, eyeball the bytes, or paste into an assignment |
| Binary | P6 | Raw bytes (1 byte per sample if maxval < 256, otherwise 2 bytes MSB-first) | ~6.2 MB | Production pipelines, larger images, anything that has to parse fast |
The xconvert converter writes the binary P6 variant by default. If your downstream tool insists on P3, run the output through pnmnoraw or open the PPM in GIMP and re-save as ASCII.
They are all part of the Netpbm family but differ in what each pixel stores. PBM (Portable Bitmap, magic P1/P4) is 1-bit black and white. PGM (Portable Graymap, P2/P5) is single-channel grayscale. PPM (Portable Pixmap, P3/P6) is three-channel RGB. PAM (Portable Arbitrary Map, P7), added to Netpbm in 2000, generalises all three and adds an alpha channel and named tuple types — pick PAM if you need transparency, otherwise PPM is the right choice for color.
PPM has no compression at all — every pixel writes 3 bytes (8-bit) or 6 bytes (16-bit) plus a tiny ASCII header. A 1920x1080 photo at 8-bit P6 is exactly 1920 x 1080 x 3 = 6,220,800 bytes plus header, regardless of content. PNG, by contrast, runs DEFLATE over a per-row pre-filter and routinely compresses photos to a quarter or less of that size, and screenshots much smaller still. The size difference is the cost of programmatic simplicity.
No. PPM stores only red, green, and blue samples, so transparent pixels are flattened against an opaque background (this converter uses white) and any alpha channel is discarded. If you need the transparency, convert to PAM (pamrgbatopng and friends) instead, or keep working in PNG until the alpha is no longer needed.
Use 8-bit (maxval 255) for screenshots, web graphics, photography, and any coursework where 256 levels per channel is fine — the file is half the size of 16-bit and almost every Netpbm tool reads it without flags. Use 16-bit (maxval up to 65535) when the source is genuinely high-precision: HDR renders, raw camera scans, scientific captures, or downstream code that does heavy arithmetic and would suffer from posterisation in 8 bits. Note that 16-bit P6 stores samples big-endian (most significant byte first) per the Netpbm spec, which catches out readers that assume native byte order.
This page outputs binary P6, which is the format almost every Netpbm tool, ImageMagick, GIMP, and OpenCV expect. P6 is also roughly three times smaller than the equivalent P3 ASCII file. If your assignment, parser, or editor specifically requires the human-readable P3 variant, run the output through Netpbm's pnmnoraw utility, or re-export from GIMP with "Data formatting: ASCII".
Yes — drop multiple PNGs onto the upload area and the converter processes them in a single browser session, keeping your chosen quality, bit depth, and resolution settings consistent across the batch. There is no per-job fee, no watermark, and the files do not leave your session unless you download them.
The Netpbm specification defines PPM samples in ITU-R BT.709 (Rec. 709) RGB with the standard BT.709 transfer function (gamma). In practice many tools treat PPM data as sRGB because the two are very close in primaries and white point, but if you need bit-exact color management you should keep an explicit ICC profile alongside the PPM, since PPM has no in-band color metadata.
Yes. Use the PPM to PNG converter to re-encode your processed pixmap with PNG's lossless DEFLATE compression for a much smaller file. If you need to feed the result into a different toolchain, PPM to JPG, PPM to BMP, or PPM to TIFF cover the most common downstream formats.
Yes — PPM has no executable chunks, no embedded scripts, and no metadata fields beyond optional # comments, so it is one of the safest image formats to share or check into version control. The downside is that, because it is uncompressed and verbose, repositories can balloon quickly; many graphics courses ask students to commit PPM only for small reference images and to use PNG for anything larger.