PNG is one of the most misunderstood file formats on the web. People reach for it out of habit, compress it wrong, serve it in the wrong situations, and then wonder why their site crawls. But flip that around — understand what's actually happening inside a PNG file, and you unlock savings that automated tools miss entirely.
This isn't a "click compress and move on" guide. It's everything: the internals of the format, the real difference between lossless and lossy strategies, the mistakes that cost you 30–60% of recoverable savings, expert tricks that require no additional tooling, and a decision framework for when to use PNG versus WebP, SVG, or JPEG. Whether you're a designer optimizing assets before handoff, a developer building a CI/CD image pipeline, or an SEO professional auditing Core Web Vitals, this is the guide you keep open.
1. What PNG actually is — and why compression is complicated
PNG stands for Portable Network Graphics. It was designed in the mid-1990s as a patent-free replacement for GIF, built around a single uncompromising principle: every pixel decoded from a PNG file must be bit-for-bit identical to the original. No information loss, ever. That lossless guarantee is both PNG's defining strength and its greatest limitation on the modern web.
Understanding the structure of a PNG file matters because it tells you exactly where the savings come from — and why naive compression tools often leave half the work undone.
The anatomy of a PNG file
A PNG file is built from a sequence of chunks — each chunk is a self-contained block with a 4-byte type identifier, a length field, the data, and a CRC checksum. The chunks that matter for compression are:
- IHDR — The image header. Stores width, height, bit depth, color type, and interlace method. This is the first decision point: the color type chosen here can dramatically inflate or deflate your file size before a single compression algorithm touches the data.
- IDAT — The image data. This is where the actual compressed pixel information lives. A PNG file can have multiple IDAT chunks, and their combined content is a single DEFLATE-compressed stream. This is where most compression effort is applied.
- PLTE — The palette. Only present in indexed-color PNGs. Defines up to 256 colors. If your image has fewer than 256 distinct colors, storing it as an indexed PNG instead of RGBA can reduce file size by 50–75%.
- tEXt / iTXt / zTXt — Metadata chunks. Creation software, author fields, copyright info, GPS coordinates embedded by phone cameras, Adobe XMP data — these chunks add nothing visually but can add dozens of kilobytes. They're pure dead weight on the web.
- gAMA, cHRM, sRGB, iCCP — Color profile chunks. The iCCP chunk especially is notorious for being embedded by design tools at full size (often 2–3 KB) when a 3-byte sRGB chunk conveys the same information.
The color type problem most people ignore
This is the single biggest missed optimization in PNG compression, and almost no beginner-facing guide covers it. PNG supports six color types, and every color type uses a different number of bytes per pixel:
| Color Type | PNG Type Code | Bytes/Pixel | Use When |
|---|---|---|---|
| Grayscale | 0 | 1 | Black-and-white images, icons |
| Indexed (Palette) | 3 | 0.5–1 (1 byte per pixel + 768-byte palette) | Flat graphics, logos, icons with <256 colors |
| RGB (Truecolor) | 2 | 3 | Photos, gradients — no transparency needed |
| RGBA (Truecolor + Alpha) | 6 | 4 | Any image needing transparency |
| Grayscale + Alpha | 4 | 2 | B&W with transparency |
| Indexed + Transparency (tRNS chunk) | 3 + tRNS | 0.5–1 | Simple transparency with <256 colors |
The most common mistake: design tools export everything as RGBA (type 6), even grayscale images and flat logos with 12 colors. An RGBA image uses 4 bytes per pixel. The same logo stored as indexed uses 1 byte per pixel — one-quarter of the raw data entering the DEFLATE compressor. Since DEFLATE's efficiency scales with the compressibility of the input, less input means dramatically better output ratios.
When you open any exported PNG, the first question to ask is: does this image actually need to be RGBA? In a surprising number of real-world assets, the answer is no.
2. How PNG compression works under the hood
PNG uses a two-stage compression pipeline. Understanding both stages explains why some tools get dramatically better results than others — and why the order of operations matters.
Stage 1: PNG filtering
Before the DEFLATE compressor ever sees a single byte of pixel data, PNG applies a reversible transformation called filtering. Filtering operates row by row and converts absolute pixel values into predictions about how each pixel relates to its neighbors. The goal is to produce a stream of small numbers rather than a stream of arbitrary color values — and small numbers compress far better in stage 2.
PNG defines five filter types that can be applied independently to each row:
Here's what most compression guides miss: the PNG specification says an encoder may choose the filter type per row. A naive encoder uses the same filter for all rows. A smart encoder (like the one in OxiPNG or libpng with optimal settings) tests multiple filter types for each row and picks the one that produces the smallest compressed output. This per-row filter optimization alone often accounts for 5–12% of IDAT savings — for free, with zero visual impact.
Stage 2: DEFLATE compression
The filtered pixel stream is then passed through DEFLATE — the same algorithm used in ZIP files and gzip. DEFLATE is a combination of LZ77 (a sliding-window dictionary compressor) and Huffman coding (a statistical bit-packing scheme). The LZ77 pass finds repeated byte sequences and replaces them with back-references. The Huffman pass then encodes the resulting symbols using fewer bits for more-frequent values.
DEFLATE has a compression level setting from 1 (fastest, worst ratio) to 9 (slowest, best ratio). Many image export tools — including Photoshop, Sketch, and some export pipelines — default to level 6 or even level 1 for speed. Recompressing at level 9 using a better DEFLATE implementation (like Zopfli, which iterates the LZ77 pass many times to find optimal back-references) can reduce IDAT size by 3–20% without changing a single pixel value.
What "lossless" actually means at the byte level
Lossless compression in PNG means the DEFLATE filter is perfectly reversible. When a browser decompresses a PNG, it gets exactly the same array of pixel values that went in. There is no approximation, no rounding, no discarding. This is why PNGs are the format of choice for anything that must remain visually exact — UI elements that will be further edited, screenshots that need to capture exact UI states, medical imaging, print-ready artwork.
But "lossless" doesn't mean "compressed as well as possible." The same pixel data can be stored in a PNG that is 40 KB or one that is 200 KB — both decode to the exact same image. The difference is entirely in how aggressively the encoder searched for the optimal DEFLATE parameters. That's the entire premise of lossless PNG recompression tools.
3. Lossless vs. lossy: choosing the right strategy
This is the most important decision in PNG compression and the one most people get wrong. The default assumption is "PNG is lossless, so use lossless compression." That thinking leaves enormous savings on the table for the vast majority of web images.
The lossless compression path
Lossless PNG optimization involves recompressing the existing pixel data more aggressively. The pixel values do not change. This is what tools like OxiPNG, Zopfli-based compressors, and optipng do.
Within the lossless path, there are still several meaningful decisions:
- Metadata stripping. Removing tEXt, iTXt, gAMA, cHRM, iCCP, bKGD, pHYs, and sBIT chunks. This is always safe for web use and should always be done first. These chunks are invisible to the browser renderer and serve no display purpose.
- Color type reduction. Converting RGBA images that contain no transparency to RGB (saving 1 byte per pixel). Converting images that use fewer than 256 colors to indexed mode. These are reversible at the PNG-reader level — the image looks identical.
- Bit depth reduction. Many tools export 16-bit PNGs when 8-bit is sufficient (24-bit and 32-bit PNGs are actually 8 bits per channel; 48-bit and 64-bit PNGs use 16 bits per channel). Web use almost never requires 16-bit depth.
- Better DEFLATE. Recompressing at higher levels, with Zopfli, and with per-row filter optimization.
Combined, these lossless techniques typically save 15–30% on images exported from design tools. On images already run through a basic optimizer, you might recover another 5–10%.
The lossy compression path
Lossy PNG optimization works by reducing the number of colors in the image — specifically by mapping the full RGB/RGBA color space down to a palette of 256 or fewer colors through a process called quantization. The output is still a valid PNG file, but the pixel values have changed. The loss is in color precision, not in pixel geometry — shapes, edges, and contrast remain sharp.
The key insight is that the human visual system is remarkably poor at distinguishing between subtle color variations, especially in complex images. A photograph originally using 16 million possible colors might be visually indistinguishable when reduced to its 256 most perceptually important ones. Quantization engines like pngquant use perceptual color spaces and dithering to minimize visible banding.
Typical savings: 50–80% reduction compared to an unoptimized PNG. On images already losslessly optimized, you're still typically saving 40–70%.
When to use each strategy
| Scenario | Strategy | Expected Savings | Risk |
|---|---|---|---|
| Logo, UI icon, flat illustration | Lossy quantization | 60–80% | Very Low |
| Screenshot with text | Lossless only | 10–25% | None |
| Photograph (in PNG) | Convert to WebP or JPEG | 70–90% | None (format change) |
| Image with transparency needed | Lossy quantization, then evaluate WebP | 50–75% | Low — check visually |
| Print-quality artwork / master file | Lossless only (or skip) | 5–20% | None |
| Medical / forensic / scientific image | Lossless only or uncompressed | 5–20% | Do not use lossy |
Dithering: the underrated quality lever
When quantization maps millions of colors to 256, it creates visible banding in gradients — smooth transitions look stepped. Dithering adds controlled noise to break up those bands, making the reduction perceptually invisible. Floyd-Steinberg dithering is the standard algorithm and is used by default in pngquant and similar tools.
However, dithering makes the resulting image harder to DEFLATE-compress (random noise is incompressible). For flat graphics with large areas of solid color — logos, icons, infographics — using no dithering at a quality setting of 80+ often produces smaller files at equivalent visual quality. For photographs and complex imagery, full dithering is almost always the right call.
4. The 8 most common PNG compression mistakes
These aren't edge cases. These are patterns seen across thousands of production sites, and each one represents recoverable file size sitting there doing nothing except slowing your pages down.
Mistake 1: Using PNG for photographs
If you're storing photographs as PNGs, stop. Photographs have millions of distinct colors, subtle gradients, and complex noise — all of which PNG's lossless approach handles very badly compared to JPEG or WebP. A 500 KB JPEG and a 2.5 MB PNG can look identical on screen. The PNG's lossless guarantee is meaningless for a photo where the "original" data is already a lossy reconstruction of reality captured through a lens and sensor.
The fix is structural, not compression-level: photographic content belongs in JPEG (for universal compatibility) or WebP (for modern browsers wanting both quality and small size). Use PNG only for images where hard edges, text, line art, or transparency make lossless preservation meaningful.
Mistake 2: Exporting RGBA when there's no transparency
Design tools default to RGBA exports because it's the safe choice — it handles everything. But if an image has no transparent pixels, that fourth alpha channel is storing 255 (fully opaque) for every single pixel. You're carrying 25% extra data that conveys zero information. A good optimizer should catch and strip this automatically, but many don't, and manually checking color type before export saves that work entirely.
Mistake 3: Never stripping metadata
An iPhone photo embedded in a PNG can carry 10–30 KB of EXIF metadata — GPS coordinates, camera model, shutter speed, focal length. Design tool exports carry Adobe XMP blocks, software version strings, and color profiles. None of this has any effect on how a browser renders the image. Stripping it is always safe for web use and is typically the fastest win available.
Mistake 4: Applying the same compression settings to every image
A flat logo with 8 colors responds completely differently to compression than a gradient-heavy illustration or a screenshot with anti-aliased text. Applying uniform settings — particularly a fixed quantization color count — produces suboptimal results across the board. Flat graphics with few colors should use indexed mode. Complex images need higher color counts and dithering. The right workflow applies different strategies based on image analysis, not a single preset.
Mistake 5: Compressing at export, then recompressing with a tool
Every design tool's export dialog has a "compression" slider or quality setting. When you then run the exported file through an external optimizer, you're doing two compression passes that can interfere with each other. Specifically, if the export tool has already stripped metadata and reduced color depth, the external tool has less to work with. The better practice: export at maximum quality / minimum compression from your design tool, then run all optimization through your dedicated compression pipeline. One pass, full control.
Mistake 6: Not checking the output visually
Lossy quantization at aggressive settings (low quality, few colors) can produce visible banding, color shifts, or edge artifacts — particularly on images with subtle gradients or skin tones. A file size number alone is not sufficient review. For any lossy compression, check the output at 100% zoom before shipping. Many tools offer a side-by-side diff view precisely for this reason. Use it.
Mistake 7: Ignoring the display size vs. intrinsic size mismatch
Compressing a 2000×2000 PNG perfectly and then displaying it in a 200×200 container is not optimization — it's negligence. The browser has to download 100× more pixel data than it renders. Resize images to their display dimensions (accounting for 2× retina) before compression. A 200×200 display slot at 2× retina needs a 400×400 image, not a 2000×2000 one. This single change routinely produces 80–95% file size reductions that no compression algorithm can match.
Mistake 8: Optimizing once and forgetting
Image assets change. New team members upload unoptimized PNGs. A CMS accepts user uploads without processing. A design tool update changes export defaults. A one-time optimization is better than nothing, but a pipeline that automatically processes images on upload or at build time is the only approach that holds under real production conditions. If you're not running image optimization as part of your deployment process, you're accumulating technical debt in kilobytes with every push.
5. Advanced tricks that most guides never mention
These techniques go beyond "use a compressor." They require understanding what's actually happening inside the file and making deliberate choices at the right stage.
Trick 1: Premultiplied alpha and edge cleanup
PNG stores "straight" alpha — each channel value is independent of the alpha value. When a browser composites a transparent PNG onto a background, it has to compute premultiplied alpha at render time. For images with semi-transparent edges (like a soft-shadowed UI element or a cutout photo), the actual RGBA values at those edges contain color information mixed with partial transparency.
Here's the trick: for images that are displayed on a known, fixed background color, you can pre-composite the semi-transparent edges against that background color and convert them to fully opaque pixels, eliminating the need for transparency entirely. The image becomes an RGB PNG instead of RGBA, saving that 25% alpha channel overhead while looking identical on the specific background it will always appear on.
This is a viable technique for logos, hero images, and feature graphics displayed on a controlled background. It's not appropriate for images used in multiple contexts.
Trick 2: Color quantization before your compressor sees it
Most one-click compression tools combine quantization and DEFLATE recompression in a single pass. But you can get better results by separating them: run a standalone palette quantization tool (like pngquant with custom settings) first, then pass the output to a pure lossless recompressor (like OxiPNG or Zopfli). The quantizer makes better decisions when it's not also trying to optimize compression, and the recompressor does a better job on the already-simplified color data.
# Pass 1: Quantize to 256 colors, quality 85-100
pngquant --quality=85-100 --speed=1 --output=step1.png input.png
# Pass 2: Lossless recompress with OxiPNG
oxipng --opt max --strip all --out output.png step1.png
In practice, this two-pass approach reliably produces files 3–8% smaller than either tool running alone on the same input.
Trick 3: Strategic use of the "none" filter on indexed PNGs
For indexed-color PNGs (palette type, ≤256 colors), the PNG filter types that reference adjacent pixels (Sub, Up, Average, Paeth) can sometimes produce worse results than the None filter. This happens because palette values are arbitrary index numbers — index 3 is not necessarily close in color to index 4, so the differences between adjacent pixels' palette indices carry no useful predictive information.
When compressing indexed PNGs, try forcing the None filter explicitly and compare against adaptive filter selection. Some tools allow this via a filter flag:
# Force filter 0 (None) only — often best for indexed PNGs
oxipng --opt max --filter 0 --strip all output.png
# Let OxiPNG try all filters and pick best
oxipng --opt max --filter 0,1,2,3,4,5 --strip all output.png
Trick 4: Palette sorting for better DEFLATE results
DEFLATE's LZ77 pass works by finding repeated sequences. In an indexed PNG, each pixel is a palette index. If adjacent pixels frequently use palette indices that are numerically close to each other, the differences between consecutive index values are small and repetitive — exactly what DEFLATE loves. Sorting the palette by color similarity (using a color-space traversal like a Hilbert curve through perceptual color space) and remapping pixel indices accordingly can produce DEFLATE savings of 2–6% with zero visual impact.
This is a niche optimization that dedicated tools rarely expose. If you're building a custom pipeline for high-volume image processing, implementing palette sorting before the DEFLATE pass is a legitimate source of consistent wins.
Trick 5: Chunk ordering and ancillary chunk management
The PNG spec allows ancillary chunks (metadata) to appear in various positions relative to IDAT chunks. For streaming web delivery, ancillary chunks that appear before IDAT mean the browser has to parse them before it can start rendering. Strip ancillary chunks entirely (as described in the metadata section) or, if they must be retained, ensure they appear after IDAT in the file. This doesn't change file size but can improve perceived performance — the browser starts rendering pixels sooner.
Trick 6: Using the pHYs chunk deliberately
The pHYs chunk stores the intended physical pixel density of an image (dots per unit). Print workflows use this to determine how large to render an image physically. On the web, browsers mostly ignore it — but some tools use it to determine how to display retina assets. Removing it saves bytes (it's a fixed 13 bytes — minor) but also removes any accidental retina scaling hint. For a clean, predictable web pipeline: strip pHYs and handle retina scaling through HTML srcset attributes instead.
Trick 7: Animated PNG (APNG) compression strategy
APNGs are PNG's answer to animated GIFs, and they suffer from terrible default compression. Each frame is stored as a full image by default. The key optimization is to store only the delta (changed pixels) between frames rather than full frames — this is called frame differencing. If you're processing APNGs, tools that support delta-frame encoding can produce files 40–70% smaller than naive full-frame APNGs of the same animation, while WebP and GIF compressors also deserve consideration for animated content.
6. When to stop using PNG entirely
One of the most effective "PNG optimization" strategies is to stop using PNG for certain use cases. This isn't a dodge — it's the correct engineering decision.
Use WebP instead when you need transparency
WebP supports both transparency (lossless mode) and lossy compression with an alpha channel. For web use where browser support is a non-issue (WebP has 97%+ global browser support as of 2026), WebP almost always beats PNG on file size while matching or exceeding visual quality. Typical savings over an equivalent optimized PNG range from 25–50% for lossless WebP and 60–80% for lossy WebP with transparency.
The common objection is "but I need the original PNG." That's a file management question, not a serving question. Keep your master file as PNG for editing. Export to WebP for delivery. These are not mutually exclusive.
Use JPEG instead for photos
A JPEG at quality 85 and a PNG of the same photograph decoded from the same original JPEG source will look essentially identical — because JPEG's lossy artifacts at quality 85 are mostly below human perceptual thresholds. The JPEG will be 70–90% smaller. There is no scenario on the public web where a photographic PNG makes sense over JPEG or WebP. The only exception is lossless photographic archives where you genuinely need to preserve exact pixel values for future processing — and even then, working in RAW or TIFF formats is preferable to PNG.
If you must compress JPEG files, we have a dedicated tool for that too.
Use SVG instead for logos and icons
If your PNG is a logo, icon, or any graphic made of geometric shapes, crisp edges, and a limited color palette, the correct format is almost certainly SVG. SVG is a vector format — infinitely scalable, resolution-independent, smaller than equivalent PNGs at any size above about 32×32, and directly manipulable via CSS and JavaScript. A PNG icon at 512×512 might be 20 KB. The SVG of the same icon might be 2 KB — and it renders perfectly at any size on any display.
Use GIF (carefully) for simple animations
GIF is obsolete for static images — PNG beats it in every metric. For animations, GIF is still widely used for compatibility and ecosystem reasons (chat embeds, CMS platforms, social media), but it's technically inferior to both APNG and WebP for animation. If you're working with GIFs and need to reduce their size, the strategies are similar to indexed PNG optimization: palette reduction, frame rate reduction, and bounds optimization (only encoding the changed region of each frame).
7. Building a real compression workflow
Individual file compression is fine for occasional work. Production image pipelines need to be automated, auditable, and consistent. Here's how to think about building one.
The decision tree before every image is processed
Every image should pass through a format decision gate before any compression is applied:
- Is this a logo, icon, or geometric vector graphic? → Convert to SVG. If SVG isn't viable, optimize as indexed PNG.
- Is this a photograph with no transparency? → Convert to JPEG (quality 82–88) or WebP lossy. Do not keep it as PNG.
- Is this a photograph with transparency? → Convert to WebP with lossy compression + alpha channel.
- Is this a UI element, screenshot, or flat graphic with transparency? → PNG is appropriate. Apply lossy quantization if color count allows, then lossless recompression.
- Is this a screen recording or animation? → Consider WebP animation, APNG, or video (mp4 with no audio). Never use unoptimized GIF for animations over 5 frames.
Sizing before compression
This always comes first. Compress a correctly-sized image, not a large image compressed as a proxy for resizing. For responsive web use, generate multiple sizes: a base size at 1× and a retina version at 2×, then use HTML srcset to serve the appropriate one:
<img
src="hero-400.webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
alt="Hero image"
width="1200"
height="630"
loading="lazy"
>
Integrating compression into CI/CD
At the build level, image compression should be a non-negotiable step — as automatic as linting or type checking. In a Node.js-based build pipeline, tools like Sharp (which wraps libvips) handle resize, format conversion, and compression in a single pass. In a Python pipeline, Pillow combined with pngquant via subprocess gives you full control. In containerized environments, ImageMagick or VIPS provide command-line interfaces that script cleanly.
The principle: images should never reach your CDN or server in their original export state. Every image passes through a compression stage that applies the correct strategy based on format detection and display context.
Auditing what you already have
Before building a forward-looking pipeline, audit what's already on your site. Tools like Lighthouse (built into Chrome DevTools), ImageOptim's batch mode, and Cloudflare's image audit features can surface exactly which images are most over-budget. Prioritize by potential savings × traffic: a 500 KB PNG on your homepage at 50,000 monthly visits is worth far more attention than a 50 KB PNG in a blog post that gets 100 views.
Setting compression targets, not just applying compression
Rather than compressing "as much as possible" and accepting whatever comes out, define explicit file size budgets per image category. Typical targets for web use:
| Image Category | Target Max Size | Format |
|---|---|---|
| Hero / above-the-fold image | 100–150 KB | WebP, JPEG |
| Product thumbnail (grid) | 20–40 KB | WebP, JPEG |
| UI icon (with transparency) | 2–8 KB | SVG, indexed PNG |
| Blog content image | 50–100 KB | WebP, JPEG |
| Logo (vector) | 1–5 KB | SVG |
| Social share image (og:image) | 50–80 KB | JPEG, WebP |
When an image exceeds budget, the response is not "compress harder" — it's to diagnose why. Is it the wrong format? Too large in dimensions? Using RGBA when RGB would suffice? The budget is a flag that triggers investigation, not a target for brute-force compression.
8. Frequently asked questions
What is the best way to compress a PNG without losing quality?
Use a lossless optimizer first — strip all metadata, reduce color depth if possible, and recompress the DEFLATE stream with a high-effort encoder like OxiPNG or Zopfli. For significant savings without any perceptible quality loss, palette quantization tools like pngquant at a quality setting of 85–100 can cut file size 50–70% while remaining visually lossless to human perception. The key is checking the output at 100% zoom before shipping.
How much can PNG files be compressed?
It depends entirely on the content. Flat graphics with few colors can compress 70–80% with lossy quantization and look identical. Complex photographs stored as PNGs might only compress 15–20% losslessly before the correct answer is to switch formats entirely. The most impactful move for many PNGs isn't better compression — it's switching to a format better suited to the content type.
Does compression make PNGs load faster?
Yes, directly. A smaller file takes less time to download over any connection. But compression is only one part of loading performance. Resize images to their display dimensions, serve them from a CDN geographically close to users, use lazy loading for below-the-fold images, and set explicit width and height attributes to prevent layout shift. Compression alone without these other steps leaves significant performance on the table.
Should I use PNG or WebP for web images?
For images requiring transparency, WebP is almost always the better choice in 2026. WebP lossless beats PNG by 25–34% in file size, and WebP lossy with alpha beats PNG by 60–80% at comparable visual quality. WebP has near-universal browser support. The only cases where PNG wins are very small flat graphics (where the overhead of WebP's format structure outweighs its compression advantages) and tools/platforms that don't support WebP output.
Does PNG compression affect image quality?
Standard PNG compression (DEFLATE recompression, metadata stripping, color type reduction) is completely lossless — the decoded image is bit-for-bit identical to the original. Lossy PNG tools like pngquant reduce the color palette, which technically changes pixel values, but at quality settings of 80+, the visual difference is below the threshold of human perception for the vast majority of real-world images. Always verify the output visually for images with subtle gradients or precise color requirements.
Why is my PNG larger after "compressing" it?
This can happen for a few reasons. If the tool added metadata it didn't strip (like a software tag or color profile), the output can be larger. If the tool changed the filter strategy to something less optimal for your image content, the DEFLATE stream can be less compact. Some tools also change bit depth or color type to a less efficient option. When this happens, compare the output file's metadata against the input using a chunk inspector and identify what was added.
Can I batch compress PNG files without losing originals?
Yes — always work from copies, never from originals. A well-structured workflow keeps originals in a source directory, processes them into an output directory, and never overwrites the inputs. Most CLI tools support this via an explicit output path flag. Our browser-based compressor works on a copy in memory and gives you a download — your original file is never modified.