PNG vs JPG for images
PNG vs JPG explained seriously: how each one compresses, when one destroys the image, and the real decision between photography, graphics, and transparency in 2026.
The team behind Polimake. We explore the intersection of technology, creativity, and automation.
The "PNG or JPG" question seems like a textbook one, but in practice it still costs money every week. One brand uploads its catalog in PNG and the page takes nine seconds to load. Another exports its logo in JPG and, against certain backgrounds, a gray halo appears around the letters. A third converts screenshots with text to JPG and the result looks as if it had been photographed through a dirty window.
These aren't aesthetic problems. They're technical decisions made badly because no one explained what each format solves.
JPG (more correctly JPEG, Joint Photographic Experts Group) and PNG (Portable Network Graphics) are not equivalent alternatives. They are two distinct answers to two distinct problems. This guide explains which one solves what, why, and when it's worth skipping both to use something more modern.
Two formats, two distinct problems
JPEG was born in 1986 as a joint effort by ISO and the then-CCITT (today ITU-T) to create an international standard for compressing photographic images. The specification was published as ISO/IEC 10918 in 1992. Its goal was practical: digital cameras and the emerging web needed to transmit photographs without overwhelming phone lines that rarely exceeded 28.8 kbps. For photographs—images with thousands of subtle tones where the human eye forgives small losses—the format worked so well that thirty years later it's still the de facto standard.
PNG is younger and was born for legal reasons. In 1994, Unisys announced it was going to start charging royalties for the LZW algorithm used by GIF, the dominant format for web graphics. The technical community reacted: within a few months, a group led by Thomas Boutell designed a patent-free, lossless format with real transparency support (8-bit alpha channel) and support for a palette of up to 16.7 million colors. The PNG 1.0 specification was published in October 1996, and the W3C elevated it to an official recommendation in 2003.
That difference in origin explains almost everything. JPEG was designed for photographs and is lossy (it loses information). PNG was designed for graphics and is lossless (it loses nothing). Mixing the uses—photography in PNG, logos in JPG—produces the disasters described at the start.
How each one compresses (and why it matters)
Understanding the mechanics of compression is what separates someone who chooses a format by intuition from someone who chooses it well.
JPEG and the cosine transform
JPEG uses the DCT (Discrete Cosine Transform) over blocks of 8×8 pixels. It translates each block into a frequency representation—from large, smooth tones to fine details and contrasts—and then discards the high frequencies that the human eye perceives less well. That reduces file size enormously, but it introduces the classic artifacts: visible blocks in flat areas, halos around sharp edges, "noise" in color transitions.
In a photograph of a sunset, the eye doesn't notice the loss. In black text on a white background, those artifacts appear as gray smudges around each letter. That's why JPG destroys screenshots and favors photographs.
JPG quality is controlled with a parameter from 0 to 100 (in most editors). The difference between 80 and 100 is usually invisible to the eye and doubles the file size. Between 60 and 80, artifacts become noticeable in flat areas. Below 60, the image starts to look washed out. As an operational reference: 75–85 is the reasonable range for web photographs; 90+ only when the image is going to be edited afterward.
PNG and lossless compression
PNG uses DEFLATE, the same algorithm as zlib and .zip files. It's lossless: the reconstructed image is bit-for-bit identical to the original. That means a PNG survives multiple edits without degrading, whereas a JPG loses quality every time it's saved again.
PNG has three practical variants:
- PNG-8: indexed palette of up to 256 colors. Very small file size. Useful for flat icons, simple graphics, and illustrations with limited palettes.
- PNG-24: 16.7 million colors, no alpha channel. An uncommon case in practice.
- PNG-32: PNG-24 plus an 8-bit alpha channel (256 levels of transparency). This is the PNG most people use when they talk about a "PNG with a transparent background."
Transparency is PNG's decisive advantage. GIF also has transparency, but binary (a pixel is either transparent or it isn't). PNG allows gradual transparency, which is what makes the soft edges of a logo possible against any background.
The real decision, by use case
The decision tree isn't "PNG or JPG" but a longer sequence.
Photography without transparency
JPG, almost always. A product photo, a portrait, a landscape, an editorial image: JPG at quality 80–85 gives a reasonable file size and a quality indistinguishable from the original at normal screen size.
If the photograph is going to live in a master file that will be re-edited several times, the original should be saved in TIFF or PSD and exported to JPG only at the end. Each successive JPG export adds artifacts.
Logo, icon, rasterized vector graphic
PNG-32 if it needs transparency, PNG-8 if not. A logo in JPG will develop visible halos against any background different from the one it had during export. It's one of the most common and most damaging mistakes for brand perception.
Better still: if you have the original vector file (SVG, AI), use SVG on the web. It weighs less than any PNG and scales without loss to any resolution. PNG is plan B when the destination doesn't accept SVG.
Screenshot with text
PNG. No discussion. JPEG's DCT wrecks the sharp edges of typography. A screenshot that takes 80 KB in PNG and looks perfect can take 50 KB in JPG and look like a bad photocopy.
Image with transparency (over a non-flat background)
PNG-32. JPG doesn't support transparency at all: any export to JPG fills the transparent area with a solid color (usually white), which makes the file useless for overlays.
Digital illustration with large flat areas
PNG-8 if the palette is limited (flat style, corporate illustration). PNG-24 if there are subtle gradients. JPG only if the illustration is very photorealistic.
Animation
Neither one. GIF, APNG, or video. PNG has no native animation (APNG is an extension supported by most modern browsers but not universally). JPEG doesn't either. For short motion, the reasonable choice today is to export to MP4 or WebM video and show it on a loop.
The real file size, with numbers
A photograph of 1920×1080 pixels, without post-processing:
- Uncompressed TIFF: ~6 MB
- PNG-24: 2–4 MB (depending on complexity)
- JPG quality 95: 600–900 KB
- JPG quality 85: 250–400 KB
- JPG quality 75: 150–250 KB
- WebP quality 85: 150–250 KB (similar to JPG 85, better visual quality)
- AVIF quality 85: 80–150 KB (half of JPG 85, superior quality)
An 800×800 logo with transparency:
- PNG-32: 30–80 KB
- Lossless WebP: 20–50 KB
- SVG (if the vector exists): 5–15 KB
These numbers are approximate but illustrate the order of magnitude. The difference between exporting well and exporting badly can be a factor of 5×, and it accumulates across an entire site.
What changed since 2010: WebP, AVIF, JPEG XL
Treating the debate as "PNG vs JPG" is a conversation from 1998. In 2026 there are three newer formats worth understanding because they change what's reasonable to use.
WebP was launched by Google in 2010. It supports both lossy compression (a JPG replacement) and lossless (a PNG replacement), it includes transparency, and it usually weighs between 25% and 35% less than its JPG/PNG equivalent at similar visual quality. Browser compatibility has been practically universal since 2020. For the web, WebP should be the default option, with JPG/PNG as a fallback only when a specific channel doesn't accept it.
AVIF (AV1 Image File Format), from the Alliance for Open Media, came out in 2019. It compresses even better than WebP—typically 50% less than JPG at the same perceived quality—and it supports HDR and color depth of up to 12 bits. Compatibility: Chrome since 2020, Firefox since 2021, Safari since 2022 (version 16). Today it's reasonable as the primary format with WebP as a fallback.
JPEG XL was standardized in 2021 as a successor to JPEG with much higher compression and lossless conversion from existing JPEG. Browser compatibility is uneven: Safari has supported it since 2023, Chrome removed it in 2023 (for now). It's interesting for professional workflows but still isn't the safe choice for the public web.
The practical rule for 2026: if the context allows modern formats, use AVIF or WebP. Reserve JPG and PNG for destinations that still don't accept them (certain emails, legacy platforms, exports for print).
How real platforms behave
Uploading an image doesn't end when you upload it. Platforms reprocess.
Instagram accepts JPG and PNG, but internally it recompresses everything to JPG with its own settings. Uploading a 5 MB PNG doesn't guarantee superior quality; in many cases it ends up looking worse than a well-prepared JPG at 1080×1350 because the internal recompression is more aggressive on large sources.
Facebook applies similar recompression. One practice that helps: upload the JPG already optimized at the exact size the platform uses, instead of letting the recompression decide.
LinkedIn and X are more lenient but also recompress. PNG with text on a flat background does maintain legibility; JPG with the same content usually degrades.
YouTube converts thumbnails to JPG regardless of the upload format. It's best to upload a high-quality JPG directly.
WhatsApp compresses photographs noticeably when they're sent as a "photo." To preserve quality, you have to send them as a "document"—but then they can't be viewed inline in the conversation.
Print and professional design: professional print workflows rarely use either JPG or PNG. They work in TIFF, PSD, or PDF/X, with CMYK color profiles and resolutions of 300 DPI. JPG and PNG are web formats; in print they're last options, not first ones.
Mistakes that cost money
Logo in JPG over variable backgrounds. The gray-white halo appears as soon as the background isn't exactly the one the image had when it was exported. Within weeks, the marketing team has twenty versions of the logo with halos of different shades circulating. Solution: always export the logo in PNG-32 with a transparent background, and better still in SVG if the destination accepts it.
An entire catalog in PNG. A store with 800 products exports each photo in PNG because "it looks better." Each image weighs 2–3 MB. The category page takes eleven seconds to load and Google drops it in ranking. The solution wasn't PNG: it was JPG quality 80 with additional compression or WebP quality 85.
Screenshots in JPG. The tool's support team sends manuals with screenshots in JPG. Small text looks blurry, users don't understand the instructions, the average ticket drags on. Solution: PNG for everything that has text.
Re-exporting JPG over JPG. Every time a JPG is opened, edited, and saved again, artifacts accumulate. After five or six edits, the image is visibly worse. Solution: master files in a lossless format (PSD, TIFF) and JPG only as a final export.
Not compressing. A JPG at quality 100 can weigh three times more than the same JPG at quality 85, with no visible difference. Tools like TinyPNG, Squoosh (from Google), ImageOptim, or automatic pipelines in Cloudinary, ImageKit, or Cloudflare Images usually reduce file size by 30–60% with no perceptible loss.
Confusing file size with dimensions. A 4000×4000 PNG displayed in a 400×400 container forces the browser to download and rescale 100 times more data than necessary. Serving different sizes depending on the device (srcset, picture) reduces file size dramatically without losing quality.
The question behind it
When a team struggles with PNG vs JPG, what's usually failing is upstream: there's no export system. Each person exports by their own criteria, the files live in different folders, versions get mixed up, and when a product image needs updating the work gets duplicated five times.
Creative operations are the workflows that bring order to that chaos: how an asset is delivered, what formats it's exported in, where the definitive version lives, who approves changes. At Polimake this is divided up like this: Studio defines the export criteria—which format for each destination, which sizes, which naming convention; Media executes that export and makes it available in its final version; Studio coordinates requests for new pieces so they don't get lost in scattered messages.
When format decisions are systemic and not individual, the problems described in the previous section stop happening. The logo is always in PNG-32 and SVG, the photos always in JPG quality 82 at several sizes, the screenshots in PNG, all with a predictable name and path.
This logic connects with how web performance is measured, how search engine optimization is approached—where image weight directly affects Core Web Vitals—and how visual consistency of brand is managed across hundreds of pieces.
A quick checklist
Before exporting, three questions:
- Is it photography or a graphic? Photography → JPG/WebP/AVIF. Graphic → PNG/SVG.
- Does it need transparency? Yes → PNG-32, WebP, AVIF, or SVG. No → any of the above.
- For what destination? Modern web → AVIF/WebP with a fallback. Email → safe JPG/PNG. Print → neither one, go to PDF/TIFF/PSD.
And before uploading:
- Is the pixel size correct for the destination, or are you serving 4000×4000 where only 400×400 is visible?
- Did you run the file through a compressor like Squoosh, TinyPNG, or ImageOptim?
- Is the file name descriptive (
logo-polimake-rgb-transparent.png) and not generic (Untitled-1.png)?
To wrap up
PNG and JPG are not competitors. They are tools that solve distinct problems—photography at low file size, graphics with clean edges and transparency—and the decision is almost always obvious once the correct problem is identified. The modern conversation is no longer "one or the other" but when it's worth jumping to WebP or AVIF, which formats each destination accepts, and how to ensure each asset is exported consistently.
What distinguishes a well-cared-for brand from a disorganized one isn't the formats themselves. It's the system that decides which format, at what size, with what name, for what use—and makes sure that decision is applied to every piece, not fifteen times at the discretion of whoever has the file open at that moment.
Quick references
- Web photography → JPG quality 80–85, ideally WebP/AVIF.
- Logo → SVG if possible, PNG-32 if not.
- Screenshot with text → PNG, never JPG.
- Image with transparency → PNG-32, WebP, AVIF.
- Print → neither JPG nor PNG; PDF/X, TIFF, PSD.
- Size → export at the actual size of use, not at 4000 pixels "just in case."
- Compression → always, via Squoosh, TinyPNG, or an automatic pipeline.