What Is a PNG File? How to Check a Portable Network Graphics File Before You Trust It

7 How Do You Open a PNG File? Six readers we tested and two viewers from outside pages

The table lists the programs we tested and the ones FileInfo names. The readers with a version number are the ones we tested. We worked on Linux, so we opened no PNG file in Windows Explorer, Paint or Photos.

Open PNG files on the command line

Three commands print the size of a PNG file. For base.png, the file command prints the type, size, bit depth, color type and interlace. The identify program adds the file size, and ffprobe prints the codec name and the pixel format.

file -b base.png
PNG image data, 320 x 240, 8-bit/color RGB, non-interlaced
identify base.png
base.png PNG 320x240 320x240+0+0 8-bit sRGB 6074B 0.000u 0:00.000
ffprobe -v error -show_entries stream=codec_name,width,height,pix_fmt -of csv=p=0 base.png
png,320,240,rgb24

All three agree on 320 by 240 pixels. The identify program prints 6074B, which is the size of the file. The ffprobe output ends with rgb24, which means 3 bytes for every pixel and no alpha channel.

Open PNG files with Python

The Python package Pillow reads the same facts. Four lines print the format, size and color mode of a PNG file. The load call decodes the pixels, so a file with damaged pixel data fails here and not at the open.

from PIL import Image
im = Image.open('base.png')
im.load()
print(im.format, im.size, im.mode)
PNG (320, 240) RGB

Pillow refused 55 of the 806 PNG files and 39 of the 52 damaged copies, so read its answer with care. The damage grid lists the copies where its pixels differed from the intact file.

Viewers and converters for PNG files

These two links open outside pages for PNG files. One comes from SysTools and one from Freeviewer. We describe them from their own pages and tested neither.

The SysTools Image Converter page lists PNG among the formats it supports and among its saving options, so it reads and writes PNG. Its demo processes the first 5 files and adds a watermark. It works on Windows and Mac.

Freeviewer's page describes an image viewer for Windows that lists PNG among its formats. It adds images in bulk, moves them up and down and prints them. We list no prices, because they change.

8 How Do You Check a PNG File? Six steps, and only the last two draw the picture

The first reads need no Python. The xxd command prints bytes, and the file command names the type of a PNG file. For base.png they show the signature, the header and the first chunk.

xxd -l 48 base.png
00000000: 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52  .PNG........IHDR
00000010: 00 00 01 40 00 00 00 f0 08 02 00 00 00 fe 4f 2a  ...@..........O*
00000020: 3c 00 00 07 d0 49 44 41 54 78 da ed 5d 6b 54 14  <....IDATx..]kT.
file -b base.png
PNG image data, 320 x 240, 8-bit/color RGB, non-interlaced

Read the first line from the left. Bytes 0 to 7, 89 50 4e 47 0d 0a 1a 0a, are the signature. Bytes 8 to 15 are the length and name of IHDR. The file command prints the width, height, bit depth, color type and interlace as words.

Step 4 starts at byte 8 of the PNG file. Every chunk has a length, a name, data and a CRC. The script walks that list and checks every CRC.

Check PNG files with Python

The script reads the signature and then every chunk. It prints the size, the header values and the chunk list, then one line that says OK or lists the problems. It inflates the pixel data to compare its size with the header, and it never changes a PNG file.

import sys, struct, zlib
SIG = b'\x89PNG\r\n\x1a\n'
DEPTHS = {0: (1, 2, 4, 8, 16), 2: (8, 16), 3: (1, 2, 4, 8), 4: (8, 16), 6: (8, 16)}
CHANNELS = {0: 1, 2: 3, 3: 1, 4: 2, 6: 4}
KIND = {0: 'gray', 2: 'RGB', 3: 'palette', 4: 'gray+alpha', 6: 'RGBA'}
ADAM7 = [(0, 0, 8, 8), (4, 0, 8, 8), (0, 4, 4, 8), (2, 0, 4, 4), (0, 2, 2, 4), (1, 0, 2, 2), (0, 1, 1, 2)]

def expected(w, h, bd, ct, il):
    bits = bd * CHANNELS[ct]
    rows = lambda ww, hh: hh * (1 + (ww * bits + 7) // 8) if ww and hh else 0
    if not il:
        return rows(w, h)
    return sum(rows((w - x + dx - 1) // dx, (h - y + dy - 1) // dy) for x, y, dx, dy in ADAM7)

def peek(path):
    b, bad, seen, idat, i, hdr = open(path, 'rb').read(), [], [], b'', 8, None
    print(f'{path}: {len(b)} bytes')
    if b[:8] != SIG:
        return print('  refused: the first 8 bytes are not 89 50 4e 47 0d 0a 1a 0a')
    while i < len(b):
        if i + 12 > len(b):
            bad.append(f'cut inside a chunk header at byte {i}'); break
        n, t = struct.unpack('>I4s', b[i:i + 8]); name = t.decode('latin1')
        if i + 12 + n > len(b):
            bad.append(f'{name} says {n} bytes but only {len(b) - i - 8} remain'); break
        data, crc = b[i + 8:i + 8 + n], struct.unpack('>I', b[i + 8 + n:i + 12 + n])[0]
        if zlib.crc32(t + data) != crc:
            bad.append(f'{name} at {i} has a wrong CRC')
        if not seen and name != 'IHDR':
            bad.append(f'first chunk is {name}, not IHDR')
        if name == 'IHDR' and n == 13:
            hdr = struct.unpack('>IIBBBBB', data)
        if name == 'IDAT':
            idat += data
        if t[0] & 32 == 0 and name not in ('IHDR', 'PLTE', 'IDAT', 'IEND'):
            bad.append(f'unknown critical chunk {name}')
        seen.append(name); i += 12 + n
        if name == 'IEND':
            break
    if 'IEND' not in seen:
        bad.append('no IEND chunk')
    elif i < len(b):
        bad.append(f'{len(b) - i} bytes after IEND')
    if hdr:
        w, h, bd, ct, cm, fm, il = hdr
        print(f'  image: {w} x {h}, bit depth {bd}, color type {ct} ({KIND.get(ct, "unknown")}), ' + ('Adam7 interlace' if il == 1 else 'not interlaced'))
        if ct not in DEPTHS or bd not in DEPTHS[ct] or cm or fm or il > 1 or not w or not h:
            bad.append('IHDR has a value the specification does not allow')
        elif ct == 3 and 'PLTE' not in seen:
            bad.append('color type 3 needs a PLTE chunk')
        else:
            try:
                raw = zlib.decompressobj().decompress(idat)
                if len(raw) != expected(w, h, bd, ct, il):
                    bad.append(f'IDAT inflates to {len(raw)} bytes, expected {expected(w, h, bd, ct, il)}')
            except zlib.error as e:
                bad.append('IDAT will not inflate: ' + str(e))
    else:
        bad.append('no usable IHDR')
    print('  chunks: ' + ' '.join(seen))
    print('  ' + ('OK: signature, chunk CRCs, header and pixel data size agree' if not bad else 'PROBLEMS: ' + '; '.join(bad)))

for p in sys.argv[1:]:
    peek(p)

Here is what it printed for three files. They are base.png, a logo with an alpha channel and a 5 frame animation.

python3 png_peek.py base.png logo.png anim.png
base.png: 6074 bytes
  image: 320 x 240, bit depth 8, color type 2 (RGB), not interlaced
  chunks: IHDR IDAT IDAT IDAT IEND
  OK: signature, chunk CRCs, header and pixel data size agree
logo.png: 2721 bytes
  image: 400 x 300, bit depth 8, color type 6 (RGBA), not interlaced
  chunks: IHDR IDAT IEND
  OK: signature, chunk CRCs, header and pixel data size agree
anim.png: 1885 bytes
  image: 160 x 120, bit depth 8, color type 6 (RGBA), not interlaced
  chunks: IHDR acTL fcTL IDAT fcTL fdAT fcTL fdAT fcTL fdAT fcTL fdAT IEND
  OK: signature, chunk CRCs, header and pixel data size agree

The first line of every answer gives the name and the size in bytes. The next lines give the picture size, bit depth and color type, then the chunks in order. The animation has acTL, fcTL and fdAT chunks, and the script lists them without decoding any frame.

python3 png_peek.py B4.png C2.png E1.png fake.png
B4.png: 3037 bytes
  image: 320 x 240, bit depth 8, color type 2 (RGB), not interlaced
  chunks: IHDR IDAT
  PROBLEMS: IDAT says 2000 bytes but only 984 remain; no IEND chunk; IDAT inflates to 38810 bytes, expected 230640
C2.png: 6074 bytes
  image: 640 x 240, bit depth 8, color type 2 (RGB), not interlaced
  chunks: IHDR IDAT IDAT IDAT IEND
  PROBLEMS: IDAT inflates to 230640 bytes, expected 461040
E1.png: 6174 bytes
  image: 320 x 240, bit depth 8, color type 2 (RGB), not interlaced
  chunks: IHDR IDAT IDAT IDAT IEND
  PROBLEMS: 100 bytes after IEND
fake.png: 10516 bytes
  refused: the first 8 bytes are not 89 50 4e 47 0d 0a 1a 0a

B4 is base.png cut in half, so its first IDAT says 2,000 bytes and only 984 remain. C2 has a width of 640 with a correct CRC, so the pixel data is half the size the header expects. E1 has 100 bytes after IEND. The file fake.png is a JPEG picture named .png and fails the first check.

What the script found in our files

The script has two limits. It does not read palette values, so the 9 badpal files pass. It does not decode filters or compare pixels, so a file with damaged pixel data and a correct size can pass. The damaged PNG files show how often decoders disagree about pixels.

Check order for any PNG file

1. 1 Copy the PNG file, write its SHA256 hash and work on the copy.
2. 2 Read the first 8 bytes of the PNG file. They must be 89 50 4e 47 0d 0a 1a 0a.
3. 3 Name the type with the file command, and compare the size with identify or ffprobe. A difference points to damage or a reader limit.
4. 4 Read the chunk list with our script. A problem names the point where the PNG file stops making sense.
5. 5 Draw the picture with two decoders, as in the Python example, and compare the sizes. Only this step reads pixels.
6. 6 Look at the picture, and check the bottom rows. A cut file can draw most of the picture and lose the last rows.

9 Is a PNG File Safe to Open? The format is quiet, and a name proves nothing

We opened no PNG file in a viewer and scanned none for malware. The six readers only read bytes. The files come from public test folders, so their contents are not the worry here.

The IANA entry says the chunk types defined in the specification only cause an image to be rendered, with one exception named gIFx. It adds that the risks of future chunk types cannot be evaluated. That describes the format. A program that reads it is a separate question, and we tested only six readers.

The rename test

We saved base.png under 7 other names, ending in .jpg, .gif, .bmp, .webp, .txt, .zip or nothing at all. The file command, Pillow, ImageMagick, ffmpeg, OpenCV and Chromium opened all 7. Every one of them reads the first bytes and not the ending.

The reverse also works. We gave 11 other files the ending .png. Seven are pictures in other formats, and four are not pictures.

The seven are JPEG, GIF, BMP, WebP, TIFF, ICO and SVG files. The four are an HTML page, a text note, an empty file and a ZIP archive. The file command named the true type of all 11, and our script refused all 11.

The decoders opened some of the seven pictures as pictures. Pillow opened 6 of the 11 PNG files, ImageMagick 5, ffmpeg 7, OpenCV 5 and Chromium 5. None of them opened the HTML page, the text, the empty file or the ZIP. If your file manager hides endings, read the first bytes of anything you doubt.

Text and metadata in a PNG file

A PNG file can store text in tEXt, zTXt and iTXt chunks, and camera data in an eXIf chunk. 161 of our 806 PNG files have one of these.

The keyword Copyright appears in 113 PNG files and Licensing in 105. Comment appears in 12 PNG files, Author in 12 and Software in 10. The keywords date:create and date:modify appear in 13 PNG files.

The 5 PNG files with an eXIf chunk showed no GPS tags in exiftool. We read no other metadata, so check your own file before you publish it. The IANA entry adds that text chunks can contain control characters, and the specification recommends filtering them before direct display.

The Pillow test folder has a file that shows why. The png_decompression_dos.png file is 6,289 bytes with a 1 by 1 picture and three zTXt chunks. Pillow refused it with the message Decompressed data too large for PngImagePlugin.MAX_TEXT_CHUNK, and the other four decoders opened it.

Bytes after the end

The security section says there could be data after the IEND chunk, and it could contain anything, including malicious code. It adds that there is no known risk of that code running when the picture is decoded. A malicious application could hide it inside an innocent looking picture and then execute it.

2 of our 806 PNG files have a single byte after IEND, and our script flags both. Our damaged copies E1 and E2 add 100 junk bytes and a ZIP header, and all five decoders drew the intact pixels. So the picture looks fine and the extra bytes stay unseen.

11 How Do You Convert a PNG File to JPG or WebP? Three pictures, six methods and what changed

We converted three PNG pictures. The photo is a 512 by 768 test picture from the Kodak set. The screenshot is a 1280 by 720 page that we rendered in Chromium. The logo is 400 by 300 with 4 colors, and 49.4 percent of its pixels are fully transparent and 18.5 percent partly transparent.

No method wins every row. JPG is far smaller for the photo and larger than PNG for the screenshot. Lossless WebP is smaller than PNG for all three. The BMP files are uncompressed and range from about 2 times the PNG size for the photo to 132 times for the logo.

Make a smaller PNG file

The optipng program rewrote the three PNG files with the same pixels. It saved 12 bytes on the photo, 6,886 bytes or 10.6 percent on the screenshot and 1,688 bytes or 62.0 percent on the logo. A higher setting, -o5, gave the same size as -o2 on all three.

So a photo gains nothing and a flat picture gains a lot. Lossless WebP gave identical pixels too, and it saved more on the screenshot and the logo. We did not test whether your software opens WebP files.

JPG is smaller for photos, with changes and no transparency

JPG at quality 85 changed 98.8 percent of the photo pixels by up to 77 levels out of 255. It changed 17.7 percent of the screenshot pixels by up to 106 levels, and the file grew to 101,281 bytes, which is 55 percent more than the PNG file.

The logo had to be flattened first. We put it over a white background, so the transparent pixels became white. After that, JPG changed 31.6 percent of the logo pixels by up to 103 levels. A JPG file cannot bring the transparency back.

256 colors and GIF

Reducing the photo to 256 colors with Pillow gave a PNG file of 263,103 bytes and changed 89.0 percent of the pixels, by up to 90 levels. The screenshot changed 0.4 percent by up to 17 levels. The logo has 4 colors, so nothing changed. We did not compare the GIF pixels.

FileInfo says GIF supports only fully opaque or fully transparent pixels, while PNG may include an 8 bit transparency channel. Our GIF logo took 2,048 bytes against 2,721 for the PNG file. We did not test how the edges look.

The commands we used

python3 -c "from PIL import Image; Image.open('photo.png').save('photo_q85.jpg', quality=85)"
python3 -c "from PIL import Image; Image.open('photo.png').save('photo.webp', lossless=True)"
optipng -o2 -quiet -out photo_o2.png photo.png
python3 -c "from PIL import Image; Image.open('photo.png').quantize(colors=256).save('photo_p8.png')"
ls -l photo* | awk '{print $5, $9}'
602078 photo.png
447076 photo.webp
602066 photo_o2.png
263103 photo_p8.png
77670 photo_q85.jpg

The first two commands save a JPG and a lossless WebP file with Pillow. The third rewrites the PNG file with optipng, and the fourth reduces it to 256 colors. The last command lists the sizes, and they match the first column of the table.