The Complete Guide to Web Image Formats

Image bytes dominate the average web page. Across the sites most people visit, images account for a larger share of transferred weight than scripts, stylesheets, and fonts combined, which makes the decision you make about web image formats one of the highest-leverage performance choices available to you. It costs nothing, requires no framework change, and frequently cuts page weight in half. It also feeds directly into Core Web Vitals: the Largest Contentful Paint element on a typical landing page is an image, and Google measures how quickly that element finishes rendering. A slow hero image is a slow page.

The confusion around image file types is understandable. Formats overlap, marketing claims exaggerate, and advice written a decade ago still circulates unchallenged. The honest answer to "what is the best image format for web use" is that four formats cover almost every real case — JPEG, PNG, WebP, and SVG — and each one wins clearly in a specific situation. Once you understand what compression actually does to your pixels, the choice stops being a guess and becomes a two-question decision.

This guide walks through how compression works, what each format is genuinely good at, and how to combine them in a production workflow. Every tool referenced here runs entirely in your browser — your images are decoded, converted, and re-encoded locally and never uploaded to a server, which is worth knowing before you drop client artwork or unreleased screenshots into a random online converter.

Lossy vs Lossless: The Idea Behind Every Format

Every image format decision traces back to one question: is the encoder allowed to throw pixels away?

Lossless compression rewrites image data more efficiently without changing a single pixel. Decode a lossless file and you get back exactly the array of pixels that went in. It works by finding redundancy — runs of identical colour, rows that resemble the row above — and describing that redundancy compactly. This is why lossless compression is spectacular on flat-colour graphics, where huge regions are identical, and mediocre on photographs, where almost every pixel differs slightly from its neighbours.

Lossy compression permanently discards information the human visual system is bad at noticing. JPEG's approach is the classic example: it converts the image to a frequency representation, then aggressively coarsens the high-frequency detail, because our eyes are far more sensitive to broad brightness changes than to fine texture. The result is dramatic — a photograph at quality 80 is routinely 10x smaller than its lossless equivalent and visually indistinguishable at normal viewing size.

Two consequences follow, and both matter in practice.

First, lossy compression is generational. Each save re-quantises data that was already quantised, so artifacts accumulate. Always re-encode from the highest-quality original you have rather than repeatedly editing and re-saving an exported JPEG.

Second, lossy compression is bad at sharp edges. The frequency-domain trick that hides detail in a photograph produces visible ringing — halos and mosquito noise — around hard boundaries like text, UI borders, and line art. This single fact explains most of the format guidance that follows.

JPEG: The Photographic Workhorse

JPEG has been the default photographic format since the early 1990s, and it earns its place. It is lossy-only, it has essentially universal support in every browser, operating system, camera, and image editor ever shipped, and it is very good at what photographs contain: continuous tone, smooth gradients, and organic texture.

Its limitations are equally clear. JPEG has no transparency support at all — there is no alpha channel, so a JPEG always fills its full rectangle. It is a poor container for screenshots, logos, or anything with crisp text, where compression artifacts show plainly. And it only encodes 8 bits per channel with subsampled colour, which is fine for the web and inadequate for archival or heavy post-processing.

For quality settings, the useful range is 75–85. Below about 70, blocking becomes visible on flat areas; above 90, file size rises steeply for improvements almost nobody perceives. If you are compressing photographs for the web, quality 80 is a defensible default and a good starting point when you feed images through the Image Compressor.

PNG: Lossless, Transparent, Precise

PNG is the lossless counterpart. It reproduces every pixel exactly and supports full 8-bit alpha transparency, meaning each pixel can be opaque, transparent, or any of 254 intermediate levels — which is what allows a logo to sit cleanly on a dark background one day and a photo the next without a visible fringe.

PNG is the right choice for:

• Screenshots, particularly UI screenshots containing text, where JPEG artifacts around glyph edges are immediately obvious
• Logos, icons, and line art when no vector source is available
• Any raster image requiring transparency
• Diagrams, charts, and flat-colour illustrations with large uniform regions and hard edges

PNG is the wrong choice for photographs. Lossless compression cannot exploit the perceptual shortcuts that make JPEG effective, so a photo saved as PNG is frequently 5–10x larger than the equivalent JPEG at no perceptible quality benefit. This is one of the most common and most expensive format mistakes on the web.

PNG-8 vs PNG-24

PNG comes in two practical variants. PNG-8 uses an indexed palette of up to 256 colours and produces dramatically smaller files for simple graphics — flat icons, simple logos, single-colour illustrations. PNG-24 stores full 24-bit colour plus an alpha channel and is what most editors export by default. If your graphic genuinely uses only a handful of colours, converting to PNG-8 can cut file size by 60–70% with no visible difference at all.

WebP: The Modern Default

WebP is the format that changed the default answer. Developed by Google and now supported by roughly 97% of browsers in use — every current version of Chrome, Firefox, Safari, and Edge — it does something no earlier web format managed: it handles both jobs well.

WebP supports lossy and lossless modes in a single format, plus alpha transparency in both. That combination is the whole point. It replaces JPEG for photographs and PNG for graphics, and it does both while being smaller:

• Lossy WebP is typically 25–35% smaller than JPEG at comparable visual quality
• Lossless WebP is typically around 26% smaller than PNG
• WebP with transparency is dramatically smaller than a PNG-24 with alpha, often by more than half

The practical rule is straightforward: use WebP as your default web delivery format for both photographs and graphics, and keep the original in its source format. Converting an existing library is mechanical work — run the files through the Image Converter, which decodes and re-encodes each image locally in your browser using the browser's own codecs, so nothing is uploaded and there is no queue, size cap, or per-file limit.

If you need to support browsers without WebP support — realistically Internet Explorer 11 and some legacy embedded webviews — serve a fallback with the picture element rather than abandoning the format:

<picture>
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Product hero" width="1200" height="630">
</picture>

The browser picks the first source it understands. Always set explicit width and height so the layout reserves space and you avoid Cumulative Layout Shift.

A Note on AVIF

AVIF, derived from the AV1 video codec, compresses better still — commonly 20–30% smaller than WebP at similar quality, with support for HDR and wide colour gamut. Browser support is around 93% and rising. The catch is encoding cost: AVIF encoding is substantially slower than WebP, and at very low quality settings it smooths fine texture in a way some people find objectionable. Use AVIF as the first source in a picture element with WebP behind it if you want maximum efficiency; WebP alone remains the pragmatic choice.

SVG: Resolution Independence

SVG is categorically different. It is not a grid of pixels but an XML description of shapes — paths, circles, gradients, text. The browser renders it at whatever size and pixel density the device requires, so an SVG logo is perfectly crisp at 24px in a navbar and at 2000px on a billboard, from the same few kilobytes.

Use SVG for:

• Logos and brand marks, which must render sharply at every size
• UI icons, where SVG can be inlined and recoloured with CSS
• Charts, diagrams, and technical illustrations built from geometric shapes
• Anything that needs to be animated or restyled after it reaches the page

SVG is not appropriate for photographs. Tracing a photo to vectors produces a file both larger and worse than the JPEG it replaced.

Two practical points. First, SVGs from design tools are usually bloated with editor metadata, unused definitions, and excessive path precision; running them through an optimiser routinely halves the file size. Second, SVG is executable content — it can contain <script> elements — so never serve user-uploaded SVGs from your own origin without sanitising them.

The Decision Framework

Comparison tables tell you what formats do. What you actually need is an order of operations. Ask these questions in sequence and stop at the first one that applies.

1. Is the image made of shapes rather than captured pixels? If it is a logo, icon, chart, or illustration and you have or can produce a vector source, use SVG. Nothing else competes on quality per byte for this content, and the decision is over.

2. Is it a photograph or photographic render? Use WebP in lossy mode, quality 75–85, with a JPEG fallback if you must support legacy browsers. Add AVIF as a first source if you want the extra 20–30%.

3. Does it need transparency, or contain sharp edges and text? Screenshots, UI captures, flat illustrations, raster logos: use WebP in lossless mode, with PNG as the fallback. If your graphic uses under 256 colours, compare against a PNG-8 export — occasionally it wins outright.

4. Is it under about 2KB and needed immediately at first paint? Consider inlining it as a Base64 data URI to eliminate a network request. See the caveats below.

5. Is it a favicon? Favicons follow their own rules, covered in the next section.

Two things to apply regardless of which branch you land on. Resize before you compress — serving a 4000px-wide image into a 800px container wastes bytes that no encoder can recover, and downscaling to the largest size actually displayed is usually a bigger win than any format change. And compress after converting, since format conversion alone leaves quality settings at the encoder default.

Favicon Formats: A Special Case

Favicons are the one place where the modern-format advice does not simply apply, because browsers, operating systems, and bookmark UIs all request different things.

ICO is a container format that holds multiple resolutions in one file. It is ancient, but favicon.ico at the site root is still requested by default by every browser, and it is what appears in some legacy contexts. A multi-resolution ICO with 16×16, 32×32, and 48×48 entries covers this.

PNG favicons are declared explicitly with <link rel="icon" type="image/png" sizes="32x32" href="..."> and are what modern browsers prefer for tab icons. The Apple touch icon — 180×180 PNG, no transparency, since iOS composites it onto a solid tile — is a separate requirement for home-screen bookmarks.

SVG favicons are supported by Chrome, Firefox, Edge, and Safari and are ideal because they render sharply at every density from one small file. They can also respond to the user's colour scheme with a prefers-color-scheme media query inside the SVG itself, so your icon adapts to dark mode.

A complete, well-covered setup is three files:

<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

Producing every required size by hand is tedious and easy to get wrong. The Favicon Generator takes a single source image — ideally a square SVG or a 512×512 PNG — and produces the full set along with the markup to paste into your <head>. One design note that matters more than format: favicons render at 16 pixels. Detail that reads beautifully in your logo disappears entirely at that size, so simplify aggressively rather than shrinking the full mark.

Base64 Data URIs: Use Sparingly

A Base64 data URI embeds image bytes directly in your HTML or CSS as text, removing one network request. That sounds like a pure win and usually is not.

Base64 encoding represents 3 bytes of binary in 4 ASCII characters, so the encoded payload is roughly 33% larger than the original file. Worse, an embedded image cannot be cached independently — it is re-downloaded with every copy of the document it lives in, and it blocks parsing of the stylesheet or HTML it is embedded in. With HTTP/2 multiplexing, the per-request cost that data URIs were invented to avoid is largely gone.

The narrow cases where inlining still wins: icons of one or two kilobytes needed during first paint, small background images in critical CSS, and self-contained artifacts like single-file HTML documents or email templates where external references are unreliable. For those cases the Image to Base64 Converter produces the encoded string and a ready-to-paste data URI. As a rough threshold, inline under 2KB, link everything above 4KB, and measure in between.

A Realistic Production Workflow

Here is how the pieces fit together for a typical site build.

Source management. Keep originals at full resolution in a lossless format — PNG for screenshots, the camera's original for photographs, the editor's native file for vector work. Never treat a web-optimised export as your master; you will need to re-encode eventually and generational loss is permanent.

Resize to purpose. Export at the maximum size the image will actually display, accounting for 2x displays. A card thumbnail shown at 400px wide needs an 800px source, not the 3000px original.

Convert to the delivery format. Run each asset through the Image Converter to produce WebP versions, keeping the JPEG or PNG original as your fallback source. Because conversion happens in the browser with local codecs, batch work on client photography or pre-launch screenshots never leaves your machine — a meaningful difference from server-side converters, which by definition receive a copy of every file you process.

Compress and verify. Push the converted files through the Image Compressor and compare against the original at full size, not at a thumbnail. The right quality setting depends on content: fine texture and gradients need more bits than flat studio backgrounds. Trust your eyes on the actual image rather than a fixed number.

Handle the icon set. Generate favicons once from a simplified square source with the Favicon Generator, and drop the resulting files at the site root.

Inline only what's critical. Convert the handful of genuinely tiny, first-paint-critical assets with the Image to Base64 Converter and leave everything else as cacheable files.

Serve correctly. Set explicit width and height on every <img>, use loading="lazy" on anything below the fold, use fetchpriority="high" on your LCP image, and set long cache lifetimes with content-hashed filenames.

Conclusion

Web image format choice comes down to two questions. Is the image built from shapes or from captured pixels? If shapes, use SVG. If pixels, does it need transparency or contain sharp edges and text? If yes, use lossless WebP with a PNG fallback; if no — meaning it is a photograph — use lossy WebP at quality 75–85 with a JPEG fallback. JPEG remains the compatibility floor for photos, PNG the compatibility floor for graphics and transparency, and WebP the format that should be doing most of your actual delivery at 25–35% less weight. Favicons need their own small set of ICO, PNG, and SVG files, and Base64 inlining is a narrow optimisation for assets of a couple of kilobytes, not a general strategy.

None of this requires new infrastructure. Resize to the size you actually display, convert to WebP, compress with a quality setting you have verified by eye, and serve with correct dimensions and caching. That sequence alone typically removes half the image weight from a page.

Start with the Image Converter — drop in your JPEGs and PNGs, get WebP out, and watch the byte counts fall. Every conversion runs locally in your browser: no upload, no account, no file ever touching a server.