DEV Community: swapfileio

Why Windows Still Can't Open HEIC Files in 2026 (And What Actually Works)

swapfileio — Thu, 04 Jun 2026 14:31:26 +0000

The scenario is familiar: someone takes a photo on an iPhone, sends it to you over email or WhatsApp. You try to open it on Windows — a warning appears: "Codec required to open this HEIC file." You click it, Microsoft Store opens to "HEVC Video Extensions," and the price says $0.99. They're asking you to pay just to view an image.

It's 2026. HEIC is 9 years old (Apple introduced it in iOS 11 in 2017), and this problem is still here. It's not a coincidence — it's a structural choice. This article explains why it's still happening and walks through 5 solutions that actually work in 2026.

What's the actual problem?

A "HEIC file" is really two technologies stacked together:

HEIF — High Efficiency Image File Format (container standard, developed by MPEG)
HEVC — High Efficiency Video Coding, aka H.265 (the compression codec, also MPEG)

Apple bundled these together and called it "HEIC." The HEIF container is a royalty-free open standard, but the HEVC codec is patent-encumbered — any company that wants to use it has to pay royalties to MPEG LA. iPhone manufacturer (Apple) already pays. Windows manufacturer (Microsoft) wants the user to cover the cost.

That's where the 99 cents come from.

Microsoft's awkward setup

Microsoft Store has two separate extensions, and the split is deliberately confusing:

HEIF Image Extensions — Free. Container support. But on its own, it can't display HEIC files because it has no HEVC decoder.
HEVC Video Extensions — $0.99. The decoder you actually need. The name is misleading; it's required for HEIC photos too.

There's also a third version, "HEVC Video Extensions (Device Manufacturer)," which is free but only ships pre-installed by OEMs (Dell, HP, Lenovo, etc.). If you bought a new Dell with Windows 11 pre-installed, you probably already have it. If you have an older machine or a custom build, you don't. The same file opens for free on an OEM machine and costs $0.99 on your personal box.

This is a freely-made choice. Microsoft has historically been reluctant to support Apple's image formats. We waited until 2024 for native AVIF in Windows. WebP support came through Chromium, not Microsoft. HEIC is the latest chapter.

Who's to blame?

Short answer: all three parties get a share.

Apple never made HEIC a real standard. When they announced it in iOS 11, they called it "the new default for the camera," but didn't invest in interoperability. iCloud Photos automatically converts HEIC to JPG when displaying on non-Apple platforms — Apple themselves know HEIC is broken outside their ecosystem, they just choose not to engage with the problem.

Microsoft owns one of the world's most popular desktop OSes and asks users to pay to open an image format. By 2026 UX standards, this is absurd. Even Linux distributions ship the same codec for free (the libheif package).

MPEG LA and the patent-pool structure underpin this whole mess. The royalty model is the polar opposite of where the open web is going — WebP and AVIF are BSD/MIT-licensed, royalty-free. They're winning for that reason.

HEIC's share will gradually erode to AVIF (royalty-free + smaller). Apple has been testing AV1 codec under the "HEIC or High Efficiency" setting since iOS 18. The problem will solve itself — but not for today's user.

5 solutions that actually work in 2026

1. Buy Microsoft HEVC Extension ($0.99) — the official path

Official, permanent, system-wide. Get "HEVC Video Extensions" from Microsoft Store, install it, done. HEIC files open natively in Windows Photos. Pay once, works forever.

When not to: You've seen 2 HEIC files in your life and want a free alternative — paying isn't worth it.

2. Convert online — free, fast, private

Got one HEIC to open? Don't bother installing anything. Convert online, download JPG, move on.

The big online converters (Smallpdf, iLovePDF, ezgif) ship with Google Analytics, Facebook Pixel, and Hotjar trackers. If your HEIC happens to be a private moment (family photo, signed document), privacy starts to matter. The honest pitch for our own tool, SwapFile.io HEIC to JPG, is the inverse of that: files auto-deleted within 1 hour, Plausible analytics only (cookieless, 1 KB), no Google Analytics, no Facebook Pixel, no signup for files under 5 MB.

When not to: Batch converting 50+ files — offline solution is faster.

3. CopyTrans HEIC for Windows — free for individuals

CopyTrans HEIC is free for personal use and installs directly (not through Microsoft Store). It enables system-wide HEIC support — thumbnails show up in File Explorer, Photos opens HEIC natively, you can drag-and-drop into Office documents.

When not to: Business use requires a license. Still, for one-off personal use, it's the lowest-friction offline option.

4. Change format on iPhone itself — the preventive fix

The most sustainable solution: fix the source. On iPhone, go to Settings → Camera → Formats → "Most Compatible". From then on, all photos are saved as JPG.

Trade-off: files are roughly 2x larger. Your iCloud quota and phone storage fill up faster. But if you're tired of dealing with HEIC problems, it's a worthwhile trade.

When not to: Using 4K Live Photos or Cinematic mode — some features depend on HEIC.

5. Open on macOS, export to JPG — if you have a Mac

macOS has had native HEIC support since High Sierra (10.13). If you have a Mac: open the file → Preview → File → Export As → JPEG → save. Fast for one-offs, slow for batches.

When not to: No Mac, no solution.

Which scenario, which solution?

A practical decision table:

Situation	Best Solution
we open 100+ HEIC files a year	#1 — Microsoft HEVC Extension ($0.99, one-time)
Family photo arrived, just want to open + move on	#2 — Convert online, download, forget
System-wide free solution	#3 — CopyTrans HEIC (personal use)
Want to fix the source	#4 — Switch iPhone to JPG
Have a Mac, quick one-off	#5 — macOS Preview + Export
Work computer, sensitive file	#2 (privacy-first) or #1 (official codec)

Frequently asked questions

Can we preview HEIC files in Outlook?
On Windows with the HEVC Video Extension installed, the Outlook Preview pane shows HEIC automatically. Web Outlook (in a browser) can't — you'll still need to convert to JPG or download and open on your desktop.

Why does WhatsApp auto-convert HEIC to JPG?
WhatsApp converts client-side because most of their recipients are on different platforms — Android, Windows web — and none of them have universal HEIC support. It's a real-world snapshot of how Apple's "HEIC works everywhere" claim plays out.

Does it make sense to convert HEIC to AVIF instead of JPG?
AVIF is royalty-free, about 20% smaller than HEIC, and supported in 94% of modern browsers. If you're putting the file on the web, AVIF makes sense. If you're archiving, JPG is safer for universal compatibility.

Will HEIC eventually go away?
Probably yes, but slowly. Apple has been testing AV1 codec since iOS 18. AVIF (royalty-free + more efficient) is on the rise. HEIC's peak was 2018-2024. By around 2030, most new content will likely be in AVIF — but solutions for years of accumulated HEIC files will still be needed.

Conclusion

The HEIC problem isn't technical; it's ecosystem politics. Three large companies (Apple, Microsoft, MPEG LA) have been arguing about "who licenses which codec" for years. In the meantime, millions of users have to browse the web to open a small file.

The solution is actually simple: pick one of the 5 paths above. Whatever your scenario, in 2026 HEIC should no longer be a barrier that stops you.

This article was originally published on SwapFile.io. SwapFile.io is a privacy-first image and PDF converter — files auto-delete in 1 hour, no Google Analytics, free for the first 6 months. Try it: swapfile.io/tools/heic-to-jpg. Feedback welcome.

How We Built a Privacy-First PDF Merger in 7 Hours: The Stack and the Lessons

swapfileio — Sun, 24 May 2026 22:59:06 +0000

TL;DR

Day 8 of building SwapFile.io (privacy-first image/PDF converter) in public. Yesterday we shipped a feature we needed ourselves: PDF Merge. Total time: ~7 hours from "do we have this?" to production. Stack: Go + Fiber + PostgreSQL + Next.js 16. The interesting bits are about what we didn't have to write.

Live: swapfile.io/en/tools/pdf-merge

The problem

Most online PDF mergers do something we didn't realize until we tested four of them: they rasterize your PDFs.

You upload a contract with selectable text, signed and form-filled. You merge it with an addendum. You download the result. The output is... a stack of images. Text is no longer searchable. Form fields are flat pixels. Bookmarks gone. File size often triples.

Smallpdf does this. iLovePDF does this. PDF24 does this in their default flow. The reason is the same for all three — they use server-side rendering tools that go through a raster pipeline because it's simpler and gives them more control over the output.

we wanted the opposite: take what we uploaded, glue them together at the structural level, give us back exactly what went in. Searchable text. Embedded fonts. Bookmarks. Form fields. All intact.

The unsexy answer: pdfunite

Poppler-utils ships with a binary called pdfunite. It's been around for over a decade. It does exactly one thing:

pdfunite in1.pdf in2.pdf in3.pdf out.pdf

It doesn't rasterize. It doesn't recompress. It opens each input as a PDF object graph, appends pages in order, fixes up the cross-reference table, writes the result. Output is byte-for-byte equivalent to the inputs for text/fonts/images.

Smallpdf could have used this. So could iLovePDF. They chose not to because their pipeline is built around server-rendered images for the preview/print path, and merging via pdfunite means having a second code path. For a solo founder, having one less code path is a feature, not a downside.

The Go wrapper

Bridging Go to pdfunite is 50 lines of stdlib subprocess code. Here's the core:

type PDFUnite struct {
    binary  string
    timeout time.Duration
}

func NewPDFUnite(timeout time.Duration) (*PDFUnite, error) {
    path, err := exec.LookPath("pdfunite")
    if err != nil {
        return nil, ErrPDFUniteMissing
    }
    return &PDFUnite{binary: path, timeout: timeout}, nil
}

func (p *PDFUnite) Merge(ctx context.Context, inputPaths []string, outPath string) (*MergeResult, error) {
    if len(inputPaths) < 2 {
        return nil, fmt.Errorf("need at least 2 input files")
    }

    args := append([]string{}, inputPaths...)
    args = append(args, outPath)

    cctx, cancel := context.WithTimeout(ctx, p.timeout)
    defer cancel()

    cmd := exec.CommandContext(cctx, p.binary, args...)
    var stderr bytes.Buffer
    cmd.Stderr = &stderr

    start := time.Now()
    if err := cmd.Run(); err != nil {
        return nil, fmt.Errorf("pdfunite failed: %v — %s", err, stderr.String())
    }
    fi, _ := os.Stat(outPath)
    return &MergeResult{
        OutputPath: outPath,
        OutputSize: fi.Size(),
        Duration:   time.Since(start),
    }, nil
}

Fail-fast at startup if the binary isn't in PATH. Hard timeout via context (120 seconds, generous for a 20-file merge). Stderr captured so failures surface to the user instead of vanishing. Done.

The migration we didn't write

This is the bit we're most pleased with.

Our conversion_jobs table looks like this:

CREATE TABLE conversion_jobs (
    id              UUID PRIMARY KEY,
    user_id         UUID NULL,
    source_format   VARCHAR(16) NOT NULL,
    target_format   VARCHAR(16) NOT NULL,
    source_size     BIGINT NOT NULL,
    output_size     BIGINT NOT NULL,
    duration_ms     INTEGER NOT NULL,
    output_path     TEXT NOT NULL,
    page_count      INTEGER NOT NULL DEFAULT 1,
    expires_at      TIMESTAMPTZ NULL
);

For convert flows, source_format and target_format are things like 'jpg' and 'webp'. The first instinct for PDF merge was to add a kind enum column ('convert' | 'pdf_merge' | ...) and store input file paths in a new JSONB column.

we almost wrote that migration. Then we noticed: the existing schema already represents everything we need. For PDF merge:

source_format = 'pdf'
target_format = 'pdf-merge' (synthetic — won't match any AllowedTarget, so it never accidentally hits the convert flow)
page_count = N where N is the number of input files (reuses the column meaningfully; "page count" of an N→1 merge = input count)
The existing 1-hour anon TTL applies
The existing cleanup goroutine cleans up the output
The existing per-IP anonymous quota counts merges as conversions

Zero migration. Zero new columns. Zero data model debt. The whole feature ships with a parallel MergePDFs service method and a new HTTP handler, both reusing the existing repository and storage paths.

This pattern — synthetic target format as a discriminator — extends cleanly to upcoming features (image → PDF will be source='image', target='pdf-create'; OCR will be target='pdf-ocr'). we get an enum-like discriminator without paying the migration tax.

The day 8 honesty section

Building in public means showing the unflattering numbers, so here are mine after one week:

15 unique visitors total (mostly us testing — self-traffic exclude was set up on day 6)
0 confirmed real conversions from external users
0 email signups (the form has been live for a week)
3 reactions, <25 views, 0 comments on the day-4 AVIF crosspost on DEV.to

Almost every solo-founder Twitter post conveniently leaves these numbers out. They're the reality of week 1. The funnel data on our dashboard says the product converts at 33% (visitor → upload → output), which sounds impressive — and is meaningless when 4 of those 5 visitors are us checking a deploy.

The bottleneck is distribution, not the product. we built PDF merge partially because we needed it, partially because "pdf merge" is a 600K/month search query and our privacy angle has a real wedge against Smallpdf et al. Whether that wedge is enough to grow past 2 visitors/day is the experiment of the next 4 weeks.

What's next

Image → PDF (combine multiple images into one PDF) — same pdfunite-style pipeline, just with ImageMagick on the way in
OCR via Tesseract — much harder; weeks of work
Distribution: awesome-list PRs, this DEV.to post, then HackerNews "Show HN" once the feature has 2 weeks of stability

Try the merger here: swapfile.io/en/tools/pdf-merge

The code is closed-source today (might change post-monetization in November). Everything you see in this post is exactly how it runs in production — no oversimplification for the article.

Building SwapFile.io in public — privacy-first image and PDF tools. Files auto-delete in 1 hour, no Google Analytics, free for the first 6 months. Feedback welcome via reply or Twitter @swapfileio.

What Is AVIF? Why It Became the Default Image Format in 2026

swapfileio — Wed, 13 May 2026 21:22:48 +0000

In this article:

What AVIF actually is, who built it, what problem it solves
Why the same image is ~50% smaller than JPEG and ~20% smaller than WebP at equivalent quality
When AVIF is the right call — and when it isn't
2026 browser support: is it finally safe to use everywhere?

Let us start with one number. The same 1920×1080 photo, encoded at the quality where the human eye can't tell them apart:

JPEG at q75: 263 KB
WebP at q75: 168 KB
AVIF at q50: 102 KB

Three formats. Same image. Same perceived quality. The AVIF version is less than 40% the size of JPEG.

That single number is why we're having this conversation in 2026. But "use AVIF" is the easy answer. The harder, more useful one is when to use it — and when not to. That's what this guide covers.

What Is AVIF, Briefly

AVIF stands for AV1 Image File Format. It was released in 2019 by the Alliance for Open Media, a consortium of companies that wanted a royalty-free, open-source image compression standard. The roster includes Google, Mozilla, Cisco, Apple, Netflix, Amazon — basically the companies that pay the most in bandwidth costs and care the most about open standards.

Why a new format at all? The image format landscape in 2019 looked like this:

JPEG (1992): Still everywhere. Still 34 years old.
PNG (1996): Lossless, but huge for photos.
HEIC (2015): Apple-developed, used by iPhones. Patent-encumbered, expensive to license.
WebP (2010): Google's attempt to replace JPEG. Got stuck because Safari took a decade to support it.

The opening: a modern, royalty-free format that actually used the latest compression research. AVIF is built on top of the AV1 video codec — the same codec YouTube and Netflix use for HD/4K streaming. AVIF is essentially "one frame of AV1 video, saved as an image."

The result: the full power of modern video compression, applied to a single still image.

How It Actually Works

You can skip this section if you don't care about the technical details — but understanding the basics helps you make better calls about when AVIF helps and when it doesn't.

AVIF compresses an image by breaking it into blocks (anywhere from 8×8 to 128×128 pixels). For each block, the encoder predicts what it should look like based on neighboring blocks, then stores only the difference between the prediction and the actual content.

Imagine you're encoding a photo of a sky. You've got 10 nearly-identical blocks of blue. AVIF says "look at the first block, the next 9 are basically the same with tiny corrections." That's intra-frame prediction, and JPEG doesn't have it. JPEG compresses every block independently. That's why JPEG creates visible banding in gradients — skies, sunsets, blurry backgrounds.

Two other technical wins worth mentioning:

Wider color depth. JPEG is locked to 8-bit per channel (256 shades). AVIF supports 10 and 12-bit (1024 and 4096 shades). This matters for HDR photos — JPEG literally can't store HDR information; AVIF can.

Alpha channel. Transparency, like PNG. AVIF supports it, JPEG doesn't, and AVIF transparent images are typically 60-80% smaller than equivalent PNGs.

AVIF vs WebP vs JPEG — Real Numbers

we tested the same 1920×1080 photo across all three formats, calibrating quality settings so the perceptual quality (measured with DSSIM) was identical:

Format	File size	vs JPEG	Encode time	Browser support
JPEG (q75)	263 KB	100%	<100ms	100%
WebP (q75)	168 KB	64%	~200ms	97%
AVIF (q50)	102 KB	39%	~1500ms	94%
AVIF (q30)	65 KB	25%	~2000ms	94%

Three takeaways:

1. AVIF wins on file size by a wide margin. Same visible quality, 60-75% less storage. The bandwidth savings are massive, especially for mobile users.

2. Encoding is slow. JPEG encodes in 50ms, AVIF can take 1.5 seconds for the same image. This isn't a user-facing problem (you only encode once), but it matters for batch jobs. AVIF uses significantly more server CPU.

3. Browser support is 94%. That means 6% of your visitors can't see AVIF. This is why fallback strategy still matters (more on that below).

When to Use AVIF (and When Not)

Switching every image to AVIF tomorrow is not the right move. Some use cases make sense, some don't. Here's how we think about it:

✅ Use AVIF

Web hero images — Page speed is critical, bandwidth matters, 6% fallback is acceptable
Photography portfolios — High resolution, lots of files, storage costs add up
E-commerce product images — Page load impacts conversion, milliseconds count
Blog cover images — Core Web Vitals affect SEO rankings
HDR photos — JPEG can't preserve HDR; AVIF can
Transparent backgrounds — Replace PNG, get 80% smaller files

❌ Don't Use AVIF (yet)

Email content — Many email clients still don't render AVIF (Outlook 2019 doesn't)
Legacy systems — Enterprise B2B tools, government portals
Print pipeline — If it's going to PDF/PSD eventually, use JPEG/PNG
Older Photoshop workflows — Pre-2022 versions can't open AVIF directly
Internal admin panels where speed doesn't matter

🟡 The Hybrid Approach (What we Actually Do)

In practice, we generate three versions of every image:

AVIF (modern browsers)
WebP (older Chrome/Firefox)
JPEG (universal fallback)

Then let the browser pick using the <picture> element:

`<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="...">
</picture>
`

The browser checks in order: Does it support AVIF? Yes → load AVIF. No? WebP? Also no? Load the JPEG. Every visitor gets the smallest file their browser can handle.

This triples your storage cost (three copies of each image), but bandwidth savings usually make up for it. If you're paying for a CDN, the numbers work out fast.

Browser Support in 2026

Last time we checked caniuse.com (early 2026), AVIF support looks like:

Chrome — Since August 2020 (5+ years)
Firefox — Since October 2021 (4+ years)
Safari — Since March 2023 (Safari 16.4+)
Edge — Since January 2024 (version 121+)
iOS Safari — Since March 2023

Total global coverage: ~94%.

What this means: Using AVIF in 2024 was an "early adopter" move. In 2026, it's a standard choice. You still need to think about the 6% fallback — that's what <picture> solves.

If your audience skews corporate (Internet Explorer might still be alive in some IT departments!) or is heavy on older Asian Samsung devices, that 94% might be lower for you. Check your actual analytics before assuming.

Converting to AVIF with SwapFile.io

This is exactly the problem SwapFile.io was built for. You want to convert old JPEGs to AVIF, but you don't have Photoshop, you don't know ImageMagick from the command line, and you definitely don't want to upload your family photos to some random cloud service.

Our JPEG to AVIF converter handles this directly:

Drop the file in the browser (under 1 second)
Conversion happens on our server
Files auto-delete after 1 hour — we never see them, no third party has access
No cloud storage. No account required (up to 15MB without signup)

We also support PNG, HEIC, WebP, GIF, and a few others — all convertible to AVIF. The full tools page lists every supported conversion.

Frequently Asked Questions

Why can't we see AVIF thumbnails in Windows Explorer?

Windows 11 doesn't ship with AVIF support by default. Install the AV1 Video Extension from the Microsoft Store (it's free). Once installed, File Explorer will show thumbnails automatically.

Photoshop won't open our AVIF file.

Photoshop CC 2022 (version 23.2) and later support AVIF natively. If you're on an older version, either upgrade or convert AVIF back to JPEG first.

Is AVIF quality worse than JPEG?

At the same file size, AVIF is better. At the same quality, AVIF is smaller. So: JPEG at quality 80 looks the same as AVIF at quality 50, but the AVIF is half the size. At very low quality settings (q20 or below), both formats produce visible artifacts, but AVIF generally degrades more gracefully.

Will AVIF preserve HDR from our iPhone photos?

Yes. AVIF supports 10-bit and 12-bit HDR. JPEG can't store HDR information (8-bit limit). If you've shot HDR on an iPhone Pro and want to preserve it when moving to a PC, AVIF is the right format.

Should we convert PNG files with transparency to AVIF?

Usually yes. PNG-to-AVIF conversion typically saves 60-80% on file size while preserving the alpha channel. The exception: tiny icons (16×16, 32×32) — at that size PNG is already small, and AVIF's encoding overhead negates the savings.

Does AVIF hurt mobile performance?

Decoding AVIF is 2-3x slower than JPEG, but on modern mobile devices the difference is measured in milliseconds. The smaller file size = faster network download more than compensates. Net effect: faster page loads on mobile.

Does using AVIF help SEO?

Not directly. But it improves Core Web Vitals (specifically LCP — Largest Contentful Paint), which is a Google ranking factor. Switching to AVIF typically drops LCP by 200-500ms. So: indirectly, yes.

The Bottom Line

One sentence: AVIF should be your default web image format in 2026, paired with a fallback strategy.

Exceptions: email, print pipelines, legacy systems. In those, stick with JPEG/PNG.

If you're currently serving JPEG and care about page speed (e-commerce, blog, portfolio), switching to AVIF typically pays back in bandwidth savings within 1-3 months. Encoding time is a one-time cost. Storage costs increase slightly. Bandwidth savings are continuous.

Your next step:

Convert 5 different photo types using our AVIF converter (portrait, landscape, product shot, screenshot, HDR)
Compare side by side — same quality? Yes → look at the file size difference
Convert the 10 most-used images on your site/blog to AVIF
Add <picture> tag fallback to your HTML
Re-run PageSpeed Insights — watch LCP drop

Related Reading:

Originally published on SwapFile.io. we're building SwapFile.io in public — a privacy-first image converter (HEIC, AVIF, WebP, JPG, PNG, BMP, TIFF, PDF). Files auto-delete in 1 hour, no Google Analytics, free for the first 6 months. Try it: swapfile.io. Feedback welcome.