The case for converting HEIC to PNG specifically
Most people who convert iPhone photos to a sharable format want JPG. JPG is universal, JPG is small, JPG is what email and Slack and web forms expect. The HEIC to JPG converter handles that case directly. But there's a smaller, real audience that needs the other direction: HEIC to PNG, lossless, every pixel preserved, no compression artifacts on text edges or sharp lines. If you're a designer pulling iPhone screenshots into Figma, a developer collecting bug-report screenshots from testers, a photographer doing pixel-perfect work in Photoshop, or anyone who needs to print or composite an iPhone photo without baking in JPG's signature softness, PNG is the right destination.
PNG is the format you reach for when "lossless" is the requirement. JPG is the format you reach for when "small enough to email" is the requirement. They're different jobs. This tool is the second of the two HEIC converters in the Microapp set, and it exists specifically because some people genuinely need the lossless path.
What "lossless" actually buys you
JPG compression works by quantizing color information in 8x8 pixel blocks, throwing away detail that the human eye is unlikely to notice at normal viewing distances. For continuous-tone photographs (a face, a landscape, a sunset) the loss is genuinely imperceptible at quality 85 or above. For images with hard edges — text overlaid on a photo, screenshots of UI, line art, charts, anything with crisp transitions between colors — JPG's block-based compression starts to show. You get faint halos around letterforms, mosquito noise around high-contrast edges, slight banding in flat gradients. Zoom in and it's obvious. At normal viewing it's subtle but real.
PNG doesn't do any of that. Every pixel is stored exactly as the source had it, with lossless zlib compression on top for file-size efficiency. Re-encode the same PNG ten times and the tenth file is bit-for-bit identical to the first. There are no generation losses, no edge artifacts, no banding. The trade is file size: PNG is significantly bigger than JPG for photographic content. For most iPhone photos, expect the PNG to be 3 to 5 times the size of the original HEIC.
Quick rule: PNG when you'll edit it again, share it pixel-perfect, or print it at large sizes. JPG when you're emailing it, posting it, or uploading it to a web form. PNG is the working copy; JPG is the shipping copy.
The file-size reality, with real numbers
Lossless preservation has a cost, and it's worth seeing the cost in concrete numbers before you commit to a workflow:
| Source HEIC | Dimensions | HEIC size | PNG output | JPG @ 92% (for comparison) |
|---|---|---|---|---|
| Outdoor portrait, iPhone 14 | 3024 x 4032 | 2.1 MB | 11.4 MB | 3.8 MB |
| Screenshot from iPhone (text-heavy) | 1170 x 2532 | 540 KB | 2.1 MB | 720 KB |
| Indoor product photo, iPhone 15 Pro | 4032 x 3024 | 3.4 MB | 16.8 MB | 5.2 MB |
| Document scan (mostly white) | 3024 x 4032 | 820 KB | 4.1 MB | 1.1 MB |
The pattern: PNG output sits roughly 5x the size of the original HEIC for photographic content, and roughly 4x for content with more flat-color regions (screenshots, document scans). JPG at 92 percent quality sits in between — about 2x the HEIC, with imperceptible quality difference for normal viewing. If you don't specifically need lossless, JPG is almost always the more practical choice. If you specifically need lossless (and you'll know if you do), PNG is the right pick and the file size is just the cost of the requirement.
Worked example: a designer pulls 12 screenshots from their iPhone into a Figma file for a UX audit. The HEIC originals total 8 MB. Converted to PNG they're 32 MB combined — completely fine for a working file that lives on the designer's machine. The PNGs go into Figma with no compression artifacts on the iOS text, and the audit document shows exactly what the user sees on their phone. Converting to JPG instead would have saved 24 MB and lost a small but visible amount of edge crispness, which defeats the whole point of an audit.
Why this tool never uploads your photos
Every other HEIC converter on the web takes the same approach: upload the photo to their server, decode and re-encode there, send you back the result. That's the easiest way to build the service, and it works, but it means your image briefly resides on someone else's infrastructure. For personal photos that's a privacy choice you probably didn't consciously make. For client work under NDA, internal product screenshots before a launch, or anything containing personally identifiable information, it's a deal-breaker.
The HEIC to PNG Converter does the conversion in your browser. It uses heic2any, which is a JavaScript wrapper around libheif — the same open-source HEIC decoder used in Linux image-processing pipelines — compiled to WebAssembly so it runs entirely client-side. The WASM binary is about 270 KB, lazy-loaded only when you open the page. From the moment your file enters the browser tab until the PNG download triggers, every byte stays on your machine.
You can verify this. Open your browser's network tab before clicking Convert. Watch the requests during conversion. There will be none — the network is silent until the page itself reloads. Compare to a typical online converter, which will show a large POST upload to their server. The difference is structural, not marketing copy.
When macOS Preview is the right tool (and when it isn't)
If you're on a Mac and you have one or two HEIC files to convert to PNG, macOS Preview already does this for free and locally. Open the HEIC in Preview, choose File > Export, pick PNG from the format dropdown, save. No upload, no third-party tool. For a single-file workflow this is fine and you don't need this tool.
The case where Preview falls apart is batches. Preview doesn't expose a batch export that respects per-file naming, so for thirty or forty files you end up either opening each one manually (slow) or writing an AppleScript (annoying). And if you're not on a Mac at all — Windows, Linux, ChromeOS, an iPad in browser — Preview isn't even an option. This tool covers both gaps: any operating system, any number of files, same browser tab.
Mac, one or two files: Preview is fine. Any number of files on Windows or Linux: this tool. Batches of dozens of photos on any OS: this tool, because per-file UX is built in.
JPG vs PNG, the decision tree
Here's the practical decision matrix between the two HEIC-output tools in the Microapp set:
| Use case | Better pick | Why |
|---|---|---|
| Sharing photos with non-Apple users | JPG | Smaller files, universal compatibility, no need for lossless |
| Posting to Instagram, Twitter, Facebook | JPG | Social platforms re-encode anyway; PNG just wastes upload bandwidth |
| Embedding in a website | WebP (via PNG to WebP) or JPG | Web doesn't reward PNG's size cost for photographic content |
| Designer pulling screenshots into Figma/Sketch | PNG | Pixel-perfect text rendering matters; PNG preserves edge detail |
| Photographer editing in Photoshop | PNG | Lossless source = no compression artifacts baked in before editing starts |
| Printing at poster size | PNG | Large prints reveal JPG compression that's invisible on screen |
| Email attachment of a document scan | JPG | PNG of a 4032 x 3024 scan is 4 MB; JPG is 1 MB; recipient doesn't care which |
| Bug-report screenshots for engineering | PNG | UI text needs to be readable; JPG can blur small fonts in screenshots |
| Compiling photos into a PDF | Use HEIC to PDF directly | Skip the intermediate step entirely |
The honest answer: most people most of the time want JPG. PNG is the right answer for a specific set of pixel-perfect workflows, and if you're in one of those workflows you already know it. If you're not sure which you need, start with JPG and only switch to PNG when something downstream specifically requires it.
EXIF, metadata, and what comes through
HEIC files from an iPhone carry a lot of metadata: capture date, GPS coordinates, camera model, lens information, exposure settings, focal length, ISO, even the orientation of the phone at the moment of capture. Some of this is useful (you want the capture date to survive); some of it is sensitive (GPS coordinates on a photo of your home address are a privacy issue if you post the file publicly).
This tool preserves the standard metadata through to the PNG output. Capture date, camera model, exposure settings, and GPS data all transit via PNG's standard tEXt and eXIf chunks. Some PNG viewers display this; others don't. Apple Photos, Adobe Bridge, ExifTool, and the macOS Finder Get Info panel all show it. Most web browsers and Windows Explorer don't show it by default but the data is still in the file.
If you're about to share a PNG publicly and want to strip GPS coordinates first, that's a separate step. Most photo-management apps have a "remove location" option in their export dialog; a dedicated metadata stripper handles it standalone. Don't assume converting to PNG removes the GPS — it doesn't. The format change preserves the metadata, by design.
Batch workflow for designers and developers
The two real batch use cases for HEIC to PNG:
Designer importing iOS screenshots: a UX researcher captures 40 screenshots across a user session, all as HEIC because that's what iOS produces. Designer drops all 40 onto this page, hits Convert, downloads them all, drags them into Figma. About two minutes of converter time. The alternative — Preview export one at a time, or asking the researcher to change their iPhone's photo format setting before the session — is either slow or requires coordination that often doesn't happen.
Developer collecting bug-report screenshots: users send in 12 screenshots of a UI bug, all HEIC because their iPhones default to it. Developer drops them all, gets PNGs back, pastes them into the Jira ticket where the engineering team can zoom in on the exact pixels of the problem area. JPG would have introduced compression artifacts in the small UI text, which is exactly the part that needs to be readable.
The 200 MB combined cap is conservative because PNG output is 3 to 5 times the size of the input HEIC; the actual memory headroom in the browser tab matters more than the input file size. If you're converting batches where the output approaches the cap, work in chunks of 10 to 20 photos at a time.
Frequently asked questions
When should I pick PNG over JPG for HEIC conversion?
Pick PNG when you need lossless conversion: photo editing, screenshot collection for design work, printing at large sizes, or downstream tools that specifically require PNG (some design software is strict about this). Pick JPG for general sharing — Slack, email, web upload forms, social media. PNG files are 3 to 5 times larger than JPG at equivalent quality, so JPG is the right default for "I just want to send this to someone."
Why are my PNG files so much bigger than the original HEIC?
PNG is lossless. It stores every pixel as captured, with only lightweight zlib compression on top. HEIC uses HEVC (H.265) compression, which is 50 to 70 percent more efficient for the same visual quality. So a 3 MB HEIC becomes a 12 MB PNG. That's expected behavior, not a bug. If file size is a constraint, use HEIC to JPG instead.
Is my photo actually staying on my machine?
Yes. The conversion uses heic2any (libheif compiled to WebAssembly) and runs entirely in your browser's WASM runtime. Your photo bytes go from your file system to browser memory to a PNG blob, never to any server. Open the browser's network tab during conversion and you'll see no outbound requests.
Does this preserve transparency?
HEIC photos from an iPhone camera don't have transparency — they're rectangular photos with opaque backgrounds. The PNG output is fully opaque. In the rare case where your HEIC has an alpha channel (some non-camera apps produce HEIC with transparency), the alpha would carry through to the PNG.
Can I batch-convert a folder of HEIC photos?
Yes. Drop multiple files or pick several at once from the file picker. Each converts independently with its own progress indicator. The 200 MB combined cap is conservative because PNG output is 3 to 5 times the size of the input HEIC; for larger batches, work in chunks of 10 to 20 photos.
What's the difference between HEIC and HEIF?
HEIF (High Efficiency Image Format) is the container. HEIC is the variant that uses HEVC compression for the image data. iPhones produce HEIC. Other devices may produce HEIF with different codecs (like AV1). This tool handles both, though iPhone HEIC is the case it's tuned and tested against.
Will the PNG keep the photo's EXIF metadata?
Most EXIF data — capture date, camera model, GPS coordinates, exposure settings — is preserved in the PNG output through PNG's standard tEXt and eXIf chunks. Apple Photos, Adobe Bridge, and ExifTool show this metadata; most web browsers and Windows Explorer don't display it by default but the data is in the file. If you need to strip GPS coordinates before sharing publicly, use a metadata stripper tool — the format change alone doesn't remove location data.
Why not just use macOS Preview to export as PNG?
Preview's PNG export works fine for one or two files. This tool wins when you have a batch (dozens of photos), when you're on Windows or Linux (no Preview), or when you want a quick browser-only workflow without opening a desktop app. The conversion math is the same — both use libheif under the hood — but the UX for batches is genuinely different.