Do extracted images keep their original bytes?

Pull pictures out of an icon, a layered drawing or a multi-page image, and some come out as exact copies while others are saved as new PNGs. What's stored inside decides which you get.

FluffyBench · 5 min read · Measured October 13, 2026 in two desktop browser runs

Copied or saved again: what's the difference?

An image container is like an envelope holding several prints: one file can carry several pictures. Taking a print out keeps it as it was; making a fresh print gives you a new copy of the picture.

FluffyBench Image Extractor copies a PNG already inside an icon byte for byte. For a TIFF page, it reads the picture into pixels and saves a new PNG.

A new PNG can keep the same width and height without keeping the original file bytes. How we measured

Which files come out as exact copies?

In FluffyBench Image Extractor, the picture's stored format decides the path. An icon can contain both PNG pictures and older picture types, so different sizes from the same icon can take different paths.

Copied unchanged: ORA preview and layer PNGs, PNG pictures in ICO, CUR and ICNS icons, and MPO pictures as JPG. Saved as new PNGs: TIFF pages, BMP pictures in ICO and CUR, classic RGB pictures in ICNS, DDS, KTX, KTX2, DCX and PCX. — MPO pictures come out unchanged as JPGs; every other extracted picture comes out as a PNG.

A layered drawing, pulled apart

A two-layer OpenRaster drawing holds a combined preview and separate layer pictures. Here are its stored PNGs beside the separate files returned by FluffyBench Image Extractor, with the same bytes preserved.

Three rows connect mergedimage.png, data/shot.png and data/graphic.png inside two-layers.ora to their separate PNG outputs: mergedimage.png: 8,627 bytes; data/shot.png: 8,627 bytes; data/graphic.png: 17,308 bytes. — In this two-layer drawing, the combined preview and the layer named shot.png store the same picture.

Doing it in FluffyBench Image Extractor

FluffyBench Image Extractor's Take setting chooses how many pictures you get: One image per file takes a drawing's preview, an icon's largest size or a TIFF's first page; Everything inside adds the other readable pictures.

One image per file versus Everything inside: OpenRaster preview versus preview plus two layers; ICO largest size versus both sizes; TIFF first page versus both pages. — The same measured inputs under both modes; the mode changes the selection, not the extraction path.

Here's the job in FluffyBench Image Extractor, from choosing a fruit drawing to downloading its preview and layers.

Step 1. Choose your container file. Keep the original if you need its layers, pages or exact container bytes.
1. Choose files opens the file picker.
2. The hint identifies the output file types.
Step 2. Choose how much to extract.
1. Everything inside takes all readable pictures.
2. One image per file takes one picture; see the mode comparison above.
Step 3. Press Extract to create separate images.
1. Extract starts processing on your device.
Step 4. The result tiles are the pictures you can save; the source group is the container they came from.
1. This heading identifies the source drawing.
2. Check this layer's pixel dimensions.
3. Download saves this picture.
Step 5. Use Download all (ZIP) when you want every result together.
1. Download all (ZIP) bundles the extracted images.

FluffyBench Image Extractor saves the pictures stored in your icon or layered drawing.

Image extractor

What about an ordinary ZIP?

An ordinary ZIP of pictures needs to be unzipped outside FluffyBench Image Extractor. Here's the refusal you'll see when you choose a ZIP instead of a recognized image container such as OpenRaster.

Step 1. An ordinary ZIP is an archive to unzip first, outside FluffyBench Image Extractor.
1. The message lists the image containers FluffyBench Image Extractor can open.

How we measured

Date: October 13, 2026. Browser: Chrome 153.0.8010.12 and Firefox 155.0. Device: Windows 11.

One image per file and Everything inside; 3 separate browser sessions per listed mode in each browser.

Generated two-layer ORA, two-size ICO, two-page TIFF, and an ordinary ZIP containing a PNG.

Image counts are separate outputs. File sizes are shown as bytes below one kilobyte and decimal KB above it, with exact byte totals; dimensions are decoded pixel width × height.

We counted each output image, read its exact size in bytes, and decoded it to get its native width and height.

The OpenRaster record identifies the merged preview and screen layer as byte-matches of Interface screenshot. The stored preview and screen layer also have matching recorded SHA-256 hashes. ICO size and dimension checks do not by themselves prove byte identity; the PNG-copy path is established by the current extractor source.

Two-layer OpenRaster: One image per file — 1 PNG · 8.6 KB (8,627 bytes) · 640 × 480 pixels; Everything inside — 3 PNGs · 8.6 KB (8,627 bytes), 8.6 KB (8,627 bytes), 17.3 KB (17,308 bytes) · each 640 × 480 pixels.

Two-size ICO: One image per file — 1 PNG · 1.2 KB (1,175 bytes) · 32 × 32 pixels; Everything inside — 2 PNGs · 337 bytes at 16 × 16 pixels; 1.2 KB (1,175 bytes) at 32 × 32 pixels.

Two-page TIFF: One image per file — 1 PNG · Chrome: 172 bytes; Firefox: 161 bytes · 24 × 16 pixels; Everything inside — 2 PNGs · Chrome: 172 bytes each; Firefox: 161 bytes each · 24 × 16 pixels per page.

The format map describes the current source paths, not additional measurements: image-ora-extract, icon-entry-png, icns-codec, image-mpo-extract, image-tiff-extract, image-texture-extract and image-dcx-extract. Classic ICNS RGB pictures are saved as new PNGs too. The walkthrough uses fruit-layers.ora; the diagrams use the recorded samples. TIFF thumbnails illustrate the decode-and-save path, not a visual-quality comparison.

These generated examples cover ORA, ICO and TIFF, plus an ordinary ZIP control. Large or damaged files, mixed batches, encrypted files, phone timing, memory use, visual quality and downloaded ZIP bytes were not measured.