Skip to content
Encoding2026-09-21Shuai Li10 min read

Image Formats Explained: JPG, PNG, WebP, HEIC, and SVG — Which One, When, and How to Convert

Five Formats, Five Jobs

Every image format embodies a bet about what matters most. JPG bet on photographs. PNG bet on precision. WebP bet on bandwidth. HEIC bet on the future (Apple's version of it). SVG bet on scalability. None of them won completely, which is why you routinely hold an image in the wrong format and need it in another one.

The shortcut to fluency is matching format to job, not memorizing specs:

FormatStrong atWeak at
JPGPhotos, opaque, final deliveryTransparency, text edges, re-editing
PNGScreenshots, text, transparency, editing mastersFile size on photos
WebPWeb delivery of everythingLegacy software support
HEICiPhone capture efficiencyEverything outside Apple's world
SVGIcons, logos, diagramsPhotographs

The rest of this guide walks through the decisions that fall out of that table — and the conversion moves when reality hands you the wrong format. Conversions linked below run in your browser on ToolVault (files stay local).

JPG: The Compressed Classic

JPG has survived thirty years because its bet was right: human eyes tolerate small errors in photographs in exchange for 10x smaller files. Two properties follow from its design that people still get burned by.

It is lossy and generational. Every save recompresses. Open a JPG, edit, save, repeat — and artifacts stack: blocky halos around sharp edges, posterized skies. The working rule is simple: edit from a lossless master (PNG or your editor's native format), export JPG once, and never re-edit the export. Check whether your workflow has a silent generation step — some chat apps and CMS platforms recompress on upload.

It has no transparency. JPG pixels are always opaque. Any WebP or PNG with an alpha channel that goes through JPG loses its transparency — composited onto white if you are lucky, onto black if you are not. Stickers, logos, and cutouts have no business being JPG, ever. Browser converters that target JPEG (including ours) fill former transparent pixels onto white before encode so you do not get black holes.

PNG: Precision at a Price

PNG is lossless: the pixels you save are the pixels you get back. That makes it the master format for anything that will be edited again, and the natural home of screenshots — flat colors, sharp text edges, and transparency all compress beautifully in its deflate model.

The flip side: PNG is the wrong answer for photographs. A photo saved as PNG routinely weighs 3-5x its JPG twin because lossless compression cannot exploit the eye's tolerance for approximation. The practical pattern most teams land on: PNG masters on disk, JPG or WebP exports for delivery.

PNG's transparency is also the quiet source of a classic bug: dark-mode UIs that assume a background color. An icon exported with transparent background looks perfect on light and vanishes on dark. The fix belongs in the asset (test on both), not in CSS heroics.

WebP: The Bandwidth Play

WebP routinely ships photos ~25-35% smaller than JPG at similar visual quality, and transparency often lands 50-70% smaller than PNG. Every modern browser renders it. The question is not whether WebP saves bandwidth — it does — but whether everything downstream of the file accepts it.

Where it still breaks in practice: some CMS upload pipelines, older Windows photo viewers, a surprising number of enterprise tools. The robust pattern for websites is <picture> with a PNG/JPG fallback rather than betting the whole audience on one format. For personal workflows, the question is just "does the destination open it" — and if not, convert WebP to JPG for compatibility or WebP to PNG when you need a lossless editing master. Going the other way for delivery: JPG to WebP or PNG to WebP.

One WebP subtlety worth knowing: animated WebP exists. Converting it through a Canvas pipeline to a static format captures the first frame only — moving content belongs in dedicated animation/video tools, not a still-image converter.

HEIC: Efficient Capture, Narrow Compatibility

iPhones shoot HEIC because it is genuinely efficient — better quality per byte than JPG at capture. The problem is everything outside Apple's ecosystem: Windows without extensions, older Office versions, half the web's upload dialogs. So HEIC owners convert, constantly, and the conversion direction depends on the destination:

  • Web or modern tools: HEIC to WebP keeps more of the size advantage with real browser compatibility
  • Universal compatibility: HEIC to JPG — the format every system since 1995 opens
  • Editing masters: HEIC to PNG — lossless from the decode onward (the HEIC itself was already lossy at capture)

A detail that surprises people: iPhone photos carry the Display P3 wide color gamut. Converting to sRGB-based formats shifts the most saturated colors by a few percent — invisible in most photos, worth knowing for vivid product shots. Chromium also cannot thumbnail HEIC before decode; a placeholder until convert succeeds is expected, not a broken upload. Multi-image HEIC (bursts / some exports) expands to one download per frame with uniquified names. Longer HEIC workflow notes live in the HEIC to JPG guide.

SVG: The One That Scales Forever

SVG is not pixels; it is geometry. That changes every rule: it scales infinitely (a logo renders crisp at 16px and 16 feet), the file is often smaller than a raster icon, and it can be restyled with CSS.

The catches: SVG carries text as font references, so a missing font changes rendering — the fix is converting text to outlines in your editor. And photographs make terrible SVGs (the format approximates them with shapes and loses badly). SVG-to-raster conversion exists for the destinations that demand pixels — render SVG to PNG at 2x-4x for retina sharpness — but that is a one-way door: rasterize too small and the resolution is gone forever, while the SVG could always have re-rendered bigger.

Honest tool boundary: the shared browser converter rasterizes SVG to JPEG or PNG. Direct SVG→WebP is not offered (engine support varies); if you need WebP, go SVG→PNG then PNG to WebP or the image compressor.

AVIF and GIF: Mentioned Honestly, Not Pretended

AVIF often beats WebP on bytes for photographic content when your encode/CDN chain supports it. ToolVault's Canvas converters and compressor do not encode AVIF — if your pipeline needs AVIF, use a dedicated encoder (cli/squoosh/CDN transform). Claiming otherwise would be false advertising.

GIF still shows up for short loops and chat stickers. Canvas still-image paths typically keep one frame. Animation belongs elsewhere; do not run a GIF through a format converter expecting the loop to survive.

Convert vs Compress: Pick the Right First Step

These are different jobs that people mash together:

GoalFirst toolWhy
Wrong container (HEIC rejected, WebP won't open)Format converter (HEIC→JPG, WebP→JPG, …)Change codec/container; size is secondary
Right format, file too heavyImage compressorRe-encode with quality / max-width; optional format switch
Both wrongConvert then compressDon't stack two lossy passes on an already-mangled export
Embed in HTML/CSSCompress → Image to Base64Base64 inflates ~33%; shrink pixels first

Order that survives contact with portals: lock the accepted format → lock pixel size → squeeze quality last. Reversing that order softens text and faces before the portal even sees the file.

What Browser Converters Actually Do (and Don't)

ToolVault's HEIC/WebP/SVG converters and the image compressor share a Canvas (and, for HEIC, heic2any/libheif WASM) path. Documented limits — same honesty as the tool UI notes:

  1. EXIF / GPS / ICC are stripped. drawImage + toBlob keep pixels only. Useful when sharing; keep a separate master if you need timestamps or location.
  2. JPEG gets a white underlay + alpha composite. Semi-transparent pixels do not become black holes.
  3. Orientation is baked when the engine allows. createImageBitmap(..., { imageOrientation: 'from-image' }) uprights many iPhone shots; sideways output usually means a truncated file or an engine that ignored EXIF.
  4. Animation collapses to one frame. Animated WebP/GIF through still converters → first frame only.
  5. Not a lossless JPEG rewrite. Even JPG→JPG (or compress-at-high-quality) is a fresh quantization.
  6. HEIC decode is on-demand WASM. Large batches can exhaust memory; triage one photo, then grow the batch.
  7. No AVIF encode in these tools (see above).

If the output must also hit a size cap (exam portals often want 30–100KB), pair format conversion with the compressor: format first, size second.

Conversion Rules That Preserve Quality

Most conversion damage is self-inflicted. Four rules cover nearly all of it:

  1. Convert lossless-to-lossy at most once. PNG to JPG at quality 90: fine. That JPG to another JPG at 85: stacking artifacts.
  2. Keep a master. Whatever you convert to for delivery, keep the highest-fidelity source. Storage is cheaper than re-shooting.
  3. Quality 75-90 is the usable band. Below 70 gradients band and skin tones posterize; above 90 you pay bytes for differences nobody sees. Our converters default near 90; the compressor's "balanced" preset sits at 80 for everyday web photos.
  4. Match the format to the destination, not to fashion. The upload form that accepts only JPG does not care that WebP saves bandwidth.

And when photos must travel as documents rather than images — receipts, ID copies — wrap them in a PDF instead of sending loose files: JPG to PDF embeds originals without re-encoding, so the quality survives the trip.

Quick Decision Cheat Sheet

You have…Destination needs…Move
iPhone HEICAny legacy uploadHEIC → JPG
iPhone HEICModern web, smaller fileHEIC → WebP
iPhone HEICFurther pixel editsHEIC → PNG
WebPOld OS / email clientWebP → JPG
PNG screenshotSmaller opaque deliveryPNG → WebP or compressor
SVG logoRaster slot / emailSVG → PNG at 2×–4×
Correct format, oversizePortal KB capCompressor (width then quality)

FAQ

Is WebP always smaller than JPG?

Often for photos at matched visual quality, but not a law — already-tiny JPEGs, or graphics that PNG/WebP-lossless handle better, can break the rule. Compare on the actual file.

Does HEIC → PNG recover what JPG would lose?

It preserves pixels after HEIC decode. Capture was already HEVC-lossy; PNG does not invent detail the HEIC never stored. It does avoid a second lossy generation if you will edit further.

Why did transparency turn white (or black) after conversion to JPG?

JPG has no alpha. Honest converters composite onto white; naive ones leave uninitialized RGB under alpha=0 (often black). Prefer PNG/WebP when transparency must survive.

Can I keep GPS after converting in the browser?

Not on the Canvas path used here — metadata is stripped by design. Convert a copy; archive the original HEIC/JPG if provenance matters.

Where does AVIF fit if the tools don't export it?

Use AVIF when your host/CDN encodes it and your audience's browsers decode it; keep JPG/WebP fallbacks. Do not wait for a Canvas toBlob('image/avif') path that these tools do not ship.

Format conversion is a privacy-relevant operation more often than it looks: the photos being converted are frequently personal. Every tool linked above processes images in your browser — the file never uploads, verifiable in DevTools while you work.

More format converters and other browser-local tools at ToolVault. Related reading: HEIC to JPG guide, Image compressor guide.

Triage notes

The framing sentence in the intro determines the whole structure: every format bets on a different "what matters most" and none wins outright, so holding images in the wrong format is the norm and conversion is a necessity. JPG's two properties are written up as "still biting people today": generational loss (artifacts stacking with each re-save — the rule is export once from a lossless master and never re-edit the export) and the absence of transparency (compositing semi-transparent pixels onto white is the honest thing for a converter to do). The conversion-versus-compression table separates the goal before the action, and its hard discipline is convert first, compress second — don't stack two lossy rounds on an already-damaged export; for portal imagery the order is more specific: lock format, then dimensions, then quality, because the reverse softens faces and text first.