DEV Community: quickconv

WebP vs AVIF vs HEIC: The Real-World Image Format Comparison (2026)

quickconv — Sat, 02 May 2026 03:42:27 +0000

WebP vs AVIF vs HEIC: The Real-World Image Format Comparison (2026)

JPEG has been the default image format for over 30 years. But in 2026, three contenders have matured enough to replace it for most use cases: WebP, AVIF, and HEIC.

This isn't a theoretical comparison. I run QuickConv, an image conversion service that processes thousands of conversions per day. Here's what I've learned from real conversion data.

The Short Answer

Format	vs JPEG (file size)	Browser support	Best for
WebP	~25–34% smaller	All modern browsers	Safe default today
AVIF	~50–70% smaller	Chrome 85+, Firefox 93+, Safari 16+	Highest compression
HEIC	~40–50% smaller	Safari only (natively)	Apple ecosystem

If you just want a recommendation: use AVIF with WebP fallback. HEIC is great for iPhone photos but a headache for the web.

WebP

WebP was developed by Google in 2010 and has been the "safe" next-gen format for years. Every major browser has supported it since 2020.

What makes it good:

Supports both lossy and lossless compression
Supports transparency (alpha channel) — unlike JPEG
Supports animation — unlike JPEG and HEIC
Available in every browser including older versions

Real compression numbers:

Using Sharp (the Node.js image processing library) at quality 80, here's what I see in practice:

Image type	JPEG size	WebP size	Reduction
Portrait photo (3MB)	3,000 KB	2,100 KB	30%
Product shot (1MB)	1,000 KB	680 KB	32%
Screenshot (500KB)	500 KB	320 KB	36%
Illustration (2MB)	2,000 KB	1,100 KB	45%

The catch: WebP's compression algorithm is dated compared to newer codecs. At the same visual quality, AVIF consistently beats it.

When to use WebP:

You need maximum browser compatibility
Your users might be on older browsers (pre-2021 Chromium)
You need animation support without GIF

AVIF

AVIF (AV1 Image File Format) is based on the AV1 video codec developed by the Alliance for Open Media. It's the youngest of the three formats (2019) but has the best compression of any widely-supported image format.

What makes it good:

Best-in-class compression — significantly better than WebP at the same visual quality
Supports HDR (High Dynamic Range)
Supports wide color gamut (P3, Rec. 2020)
Open standard — no licensing fees

Real compression numbers (quality 65):

Image type	JPEG size	AVIF size	Reduction
Portrait photo (3MB)	3,000 KB	900 KB	70%
Product shot (1MB)	1,000 KB	320 KB	68%
Screenshot (500KB)	500 KB	190 KB	62%
Illustration (2MB)	2,000 KB	700 KB	65%

I use quality 65 for AVIF in QuickConv's defaults. This might sound low, but AVIF's perceptual quality at 65 is equivalent to JPEG at 85. The codec is fundamentally more efficient.

The catch: Two issues.

First, encoding is slow. AVIF encoding takes significantly longer than JPEG or WebP. A 3MB JPEG converts to WebP in ~100ms; the same file to AVIF takes ~800ms–2s. For a conversion service this matters — it's why I run Sharp on Cloud Run rather than trying to do it in a serverless function.

Second, browser support has a floor. Chrome 85+ (August 2020), Firefox 93+ (October 2021), Safari 16+ (September 2022). If you have users on old iOS devices (pre-iPhone 8 which maxes out at iOS 16 but some older models are stuck on iOS 15), they'll get a broken image without a fallback.

When to use AVIF:

Maximum compression is the priority (e-commerce, media sites)
You can serve WebP as fallback with <picture> element
You control the encoding pipeline and can afford the extra CPU time

HEIC

HEIC (High Efficiency Image Container) is Apple's format, introduced with iOS 11 in 2017. Your iPhone takes photos in HEIC by default unless you've changed settings.

What makes it good:

Excellent compression — similar to AVIF
Native integration in Apple ecosystem (iOS, macOS)
Supports Live Photos (image + video together)
Apple devices shoot in this format by default

The catch: HEIC is an Apple proprietary format (based on HEVC/H.265 which has patent licensing). Windows doesn't support it natively. Android doesn't support it. No browser outside Safari supports it.

This is why HEIC is the #1 format people ask to convert on QuickConv. They shoot on iPhone, try to send the photo, and find that Windows/Gmail/Slack can't display it.

Browser support as of 2026:

Browser	HEIC support
Safari (macOS/iOS)	✅ Native
Chrome	❌ None
Firefox	❌ None
Edge	❌ None

When to use HEIC:

You're storing photos for personal use in the Apple ecosystem
You're building Apple-specific apps (iOS, macOS)
Never for web delivery

Browser Support Deep Dive

For web delivery, browser support is the deciding factor. Here's the current state:

<!-- The pattern that handles all cases -->
<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

This serves AVIF to browsers that support it, WebP as the first fallback, and JPEG as the final fallback. In 2026, the JPEG fallback only matters for IE11 (which you should have stopped supporting years ago) and a handful of obscure browsers.

Coverage breakdown:

AVIF: ~93% of global browser usage (caniuse.com, April 2026)
WebP: ~97% of global browser usage
HEIC: ~19% (Safari only)

Encoding Speed Comparison

If you're building a pipeline that converts images, encoding speed matters. Here are real measurements from the QuickConv converter running on Node.js 22 with native Sharp:

Input	Output	File size	Time
3.6MB JPG	WebP (q80)	1.9MB	~300ms
3.6MB JPG	AVIF (q65)	1.1MB	~1,800ms
3.6MB JPG	HEIC	—	Not supported in Sharp
134KB JPG	WebP (q80)	89KB	~80ms
134KB JPG	AVIF (q65)	41KB	~420ms

AVIF encoding is consistently 5–6x slower than WebP. For batch processing or real-time conversion, this adds up. For static site assets pre-built at deploy time, it doesn't matter.

HEIC encoding is not supported in most open-source libraries (Sharp, ImageMagick) due to patent licensing. You can decode HEIC (read iPhone photos), but encoding to HEIC requires Apple's frameworks or commercial software.

Lossless Comparison

All three formats support lossless compression, but there are differences:

WebP lossless: Reliably good. ~20–30% smaller than PNG for most images.
AVIF lossless: Better than WebP lossless in theory, but support is inconsistent across encoders.
HEIC lossless: Supported but rarely used outside Apple's own stack.

For lossless web images (logos, icons, UI elements), I generally recommend WebP lossless for its broad support and predictable behavior. For truly lossless archival, stick with PNG.

Transparency (Alpha Channel)

Format	Transparency
JPEG	❌ None
WebP	✅ Yes
AVIF	✅ Yes
HEIC	✅ Yes
PNG	✅ Yes

All three next-gen formats support transparency, which makes them viable replacements for PNG as well as JPEG.

My Recommendations by Use Case

Web images (photos): AVIF with WebP fallback

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

Web images (logos/icons with transparency): WebP (lossless) with PNG fallback

E-commerce product shots: AVIF — the file size savings directly reduce LCP (Largest Contentful Paint) and improve Core Web Vitals

iPhone photos for sharing: Convert HEIC → JPEG or WebP — most recipients and platforms handle both

iPhone photos for web upload: Convert HEIC → WebP before upload if your backend doesn't handle HEIC natively

Archival/editing: Keep originals in whatever format your camera produces (HEIC for iPhone, RAW for DSLR). Convert to JPEG/WebP only for distribution.

How to Convert

If you need to convert between these formats:

Command line (Sharp/Node.js):

# JPEG to WebP
sharp input.jpg --output output.webp --quality 80

# JPEG to AVIF
sharp input.jpg --output output.avif --quality 65

# HEIC to WebP (requires libvips with HEIC support)
sharp input.heic --output output.webp

Online (no install):
QuickConv — free tier handles 10 conversions/day, no account required. Supports HEIC, WebP, AVIF, PNG, JPG in any combination. Files auto-delete after 24 hours.

API (for automated pipelines):

curl -X POST https://api.quickconv.cc/v1/convert \
  -H "Authorization: Bearer qc_YOUR_API_KEY" \
  -F "file=@photo.heic" \
  -F "output_format=webp"

The Bottom Line

WebP is the safe, universal choice. Use it if you want one format that works everywhere.
AVIF is the best format technically. Use it with a WebP fallback for maximum compression.
HEIC is for Apple devices only. Convert it to anything else before sending to the web.

JPEG isn't going away — it's too deeply embedded in tooling and infrastructure. But for any new image pipeline built in 2026, there's no good reason to produce JPEG as your primary format.

Benchmarks measured on Node.js 22 with Sharp 0.33, running on GCP Cloud Run (2 vCPU). Results vary by image content.

QuickConv converts between WebP, AVIF, HEIC, PNG, JPEG, and more.

Claude Code on the Web: Why Your .env Vars Don't Reach the Setup Script (and How SessionStart Hook Fixes It)

quickconv — Sun, 19 Apr 2026 14:41:09 +0000

TL;DR

Environment variables you put in the .env panel of Claude Code on the web (Cloud Sandbox) do not reach the setup script.
They only reach the shell inside the running Claude Code session.
So git clone "https://x-access-token:${GH_TOKEN}@..." inside the setup script fails — GH_TOKEN is empty at that point.
Move the clone into a SessionStart hook and it just works, because by then $GH_TOKEN is populated.

This is a write-up of how I narrowed down a behavior that the official docs don't spell out clearly.

Background

What I wanted to do

I've been collecting custom slash commands, skills, and a personal CLAUDE.md under ~/.claude/ locally. I wanted the same setup available inside Claude Code on the web. Everything is stored in a private repo called miyashita337/agent-base.

According to the docs, cloud sessions do not carry over user-level settings like ~/.claude/CLAUDE.md — only what's committed to the repo is available. So my plan was: on session start, clone agent-base and symlink its contents into ~/.claude/.

First attempt (failed)

I put a GitHub PAT into the .env panel of the Cloud Sandbox settings and tried to clone from the setup script.

# setup script
#!/bin/bash
set -e
git clone "https://x-access-token:${GH_TOKEN}@github.com/miyashita337/agent-base.git" "$HOME/agent-base"

.env panel:

GH_TOKEN=github_pat_...   # ~90 chars, real value
GIT_AUTHOR_NAME=miyashita337
...

Result: fatal: could not read Username.

Narrowing it down

Symptom 1: my `echo` output never showed up

For debugging I added echo "GH_TOKEN length: ${#GH_TOKEN}" in the setup script. But the setup-script UI only shows the last few lines of output, so anything mid-script gets silently dropped.

Workaround: dump everything to a log file

I rewrote the script to redirect diagnostics into /tmp/env-diag.log and then cat it from inside the session.

#!/bin/bash
set -e

LOG=/tmp/env-diag.log

{
  echo "===== ENV DIAGNOSTICS ====="
  echo "GH_TOKEN length: ${#GH_TOKEN}"
  echo "GIT_AUTHOR_NAME: [${GIT_AUTHOR_NAME}]"
  echo "TZ: [${TZ}]"
  echo "LANG: [${LANG}]"
  echo ""
  echo "--- All env vars (names only) ---"
  env | cut -d= -f1 | sort
} | tee "$LOG"

Then I started a new session and asked Claude Code to cat /tmp/env-diag.log.

Symptom 2: the cache trap

On some runs I didn't even see the "setup script executed" log line. Per the docs, the setup script runs only on first creation — after that, a filesystem snapshot is reused. Editing the .env panel alone does not invalidate the snapshot.

What does invalidate it:

Changing the setup script body
Changing the allowed-domains list
~7 days of age

So I added a throwaway comment line like # cache-bust 2026-04-19-01 at the top of the setup script. Semantically it's a no-op, but it's enough to force a rerun on the next session.

The result: every env var was empty

===== ENV DIAGNOSTICS =====
GH_TOKEN length: 0
GIT_AUTHOR_NAME: []
TZ: []
LANG: []
...
Custom vars found: 0 / expected 8

It wasn't just GH_TOKEN — nothing from the .env panel was reaching the setup script.

The clincher: the session shell has them

Inside the running Claude Code session, I checked the same variables directly from the shell:

$ echo "GH=${#GH_TOKEN}, TZ=[$TZ], LANG=[$LANG]"
GH=93, TZ=[Asia/Tokyo], LANG=[ja_JP.UTF-8]

All present. So:

When it runs	`.env` panel vars available?
Setup script	❌ No
Claude Code session shell	✅ Yes

Root cause and fix

Root cause

The .env panel is injected only into the Claude Code session shell, not into the setup script. It's not a bug — it's just not documented clearly. The docs show GH_TOKEN as an example .env value, but that's aimed at the gh CLI picking it up inside the session, not at setup-script usage.

Fix: move clone logic into a SessionStart hook

Drop the clone from the setup script. Put it in a SessionStart hook defined in the repo's .claude/settings.json. The hook runs after Claude Code has started, so $GH_TOKEN is in scope.

.claude/settings.json

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/scripts/setup-agent-base.sh"
          }
        ]
      }
    ]
  }
}

scripts/setup-agent-base.sh

#!/bin/bash
set -e

AGENT_BASE_DIR="$HOME/agent-base"

# Skip locally
[ "$CLAUDE_CODE_REMOTE" != "true" ] && exit 0

# Clone (GH_TOKEN is available at this point)
if [ ! -d "$AGENT_BASE_DIR" ]; then
  if [ -z "${GH_TOKEN:-}" ]; then
    echo "setup-agent-base: GH_TOKEN is not set" >&2
    exit 1
  fi
  # Pass the token via extraHeader so it doesn't end up in .git/config
  git -c http.extraHeader="Authorization: Bearer ${GH_TOKEN}" \
      clone "https://github.com/miyashita337/agent-base.git" "$AGENT_BASE_DIR"
  git -C "$AGENT_BASE_DIR" config --unset-all http.extraHeader 2>/dev/null || true
fi

# Symlink into ~/.claude/ (idempotent)
mkdir -p "$HOME/.claude"
for dir in commands skills agents hooks; do
  src="$AGENT_BASE_DIR/$dir"
  dst="$HOME/.claude/$dir"
  if [ -d "$src" ]; then
    # If the destination is a real directory, back it up first
    # (ln -sf into an existing dir creates a nested symlink inside it)
    if [ -d "$dst" ] && [ ! -L "$dst" ]; then
      mv "$dst" "${dst}.bak.$(date +%s)"
    fi
    ln -sfn "$src" "$dst"
  fi
done

if [ -f "$AGENT_BASE_DIR/CLAUDE.md" ]; then
  ln -sf "$AGENT_BASE_DIR/CLAUDE.md" "$HOME/.claude/CLAUDE.md"
fi

exit 0

A few deliberate choices:

CLAUDE_CODE_REMOTE guard — early-exit outside of cloud sessions so local dev isn't affected.
Idempotent — skip clone if the dir exists, but always refresh the symlinks. Partial-failure recovery just works.
No token in the URL — use http.extraHeader so .git/config never contains a plaintext token.
ln -sfn not ln -sf — if the destination is already a real directory, ln -sf nests the symlink inside it (e.g. ~/.claude/commands/commands). Backing it up first and using -n (--no-dereference) forces a clean replacement.

What about the setup script?

Leave it empty. You can delete the diagnostics too.

Verification

Fresh session, ls -la ~/.claude/:

CLAUDE.md -> /home/user/agent-base/CLAUDE.md
commands  -> /home/user/agent-base/commands
skills    -> /home/user/agent-base/skills
agents    -> /home/user/agent-base/agents
hooks     -> /home/user/agent-base/hooks

Typing / shows all the custom slash commands from agent-base (/capture, /pdca, /inv, ...) and they execute without issue.

Gotchas summary

Gotcha	Fix
`.env` vars don't reach the setup script	Move clone into a SessionStart hook
Setup-script `echo` output is truncated	Redirect to a log file and `cat` it later
Setup script is cached and won't rerun	Add/edit a throwaway comment to bust the cache
New sessions can't start with an empty prompt	Type anything — but remember it becomes the first instruction to Claude
`ln -sf` doesn't overwrite existing directories	Back up first, then `ln -sfn`
`git clone https://x-access-token:${TOKEN}@...` leaks the token into `.git/config`	Pass it via `-c http.extraHeader=...` instead

Closing

The "setup script can't see .env vars" behavior is inferable if you read the docs carefully — the gh CLI example hints at "this is for in-session auto-pickup" — but it's never stated plainly. Easy to misread as "you can use these in the setup script too."

Hope this saves someone else the afternoon I lost.

References

Use Claude Code on the web — Claude Code Docs
Hooks configuration — Claude Code Docs
Original Japanese post: https://zenn.dev/harieshokunin/articles/b1064354319ce2

I Built an Image Conversion SaaS on (Almost) $0/Month — Here's the Full Stack

quickconv — Fri, 17 Apr 2026 12:37:03 +0000

I Built an Image Conversion SaaS on (Almost) $0/Month — Here's the Full Stack

A few months ago I got frustrated trying to convert a HEIC photo on my iPhone into something my client could actually open. The tools I found were either slow, ugly, or locked behind a paywall after one use. So I built QuickConv — a file conversion service focused on next-generation image formats like WebP, AVIF, and HEIC.

This post is a full technical breakdown: what I chose, why I chose it, and what I'd do differently. No marketing fluff.

Architecture Overview

Here's the bird's-eye view:

Browser (Next.js static)
        │  HTTPS
        ▼
Cloudflare Pages  (CDN edge, static HTML/JS)
        │
        │  API calls
        ▼
Cloudflare Workers  (Hono — api.quickconv.cc)
        │               │
        │ R2 presign     │ convert job dispatch
        ▼               ▼
Cloudflare R2     GCP Cloud Run  (Sharp / FFmpeg / Ghostscript)
(file storage)          │
        ▲               │ callback on completion
        └───────────────┘
              │
              ▼
        Cloudflare D1
        (job state, rate limits, users)

The key design decision: split sharp-based conversion into a separate container rather than running it inside Workers. That single choice drove most of the rest of the architecture.

Frontend: Next.js with Static Export

The frontend is a Next.js 15 App Router app. The entire build is configured as a static export:

// apps/web/next.config.ts
const nextConfig: NextConfig = {
  output: "export",
  productionBrowserSourceMaps: true,
};

output: "export" means next build produces a directory of static HTML, JS, and CSS — no Node.js server required. That output gets deployed directly to Cloudflare Pages.

Why static export?

Cloudflare Pages serves static assets from its global CDN at no compute cost
No cold starts, no server to manage
Pages has a generous free tier (unlimited requests for static assets)

The tradeoff: no server-side rendering per request. For a conversion tool this is fine — the page content doesn't change per user. Dynamic data (job status, user account) is fetched client-side from the API.

Internationalization is handled by next-intl with ja and en locale support baked into the static export. The locale is resolved from the URL path (/en/, /ja/).

API Layer: Hono on Cloudflare Workers

The API is a Hono application deployed to Cloudflare Workers at api.quickconv.cc.

/api/upload    — receive file, store in R2
/api/convert   — create job, dispatch to converter
/api/status    — poll job state from D1
/api/download  — stream converted file from R2
/api/auth      — Google OAuth (JWT cookie)
/api/checkout  — Stripe checkout session
/api/webhook   — Stripe webhook handler
/api/account   — subscription info
/v1/convert    — public API for developers (API key auth)

Why Hono instead of Express or Fastify?

Three reasons:

Workers compatibility. Express and Fastify are built around Node.js APIs (http.IncomingMessage, Buffer, etc.) that don't exist in the Workers runtime. Hono is built on the Web Standard APIs (Request, Response, Headers) that Workers natively support. No polyfills, no shims.
TypeScript ergonomics. Hono has excellent type inference for route handlers, middleware, and context variables. The Bindings and Variables generics let me type-check R2 bindings, D1 bindings, and middleware-set values at compile time.
Size. Workers have a 1MB (compressed) script size limit. Hono is tiny.

The middleware stack in order: Sentry → CORS → identification → optional auth → cost guard → rate limit.

The identification middleware generates a stable clientHash from IP + User-Agent (hashed, no PII stored) to track anonymous usage for rate limiting without requiring login.

Conversion Engine: Sharp on GCP Cloud Run

This is where things get interesting.

Why not run Sharp in Workers?

Workers run in V8 isolates — a JavaScript-only sandbox. Sharp is a native Node.js addon built on libvips. Native binaries cannot run in V8 isolates. You can run WebAssembly in Workers, and there is a sharp WASM build, but as of writing it doesn't support AVIF encoding and is significantly slower for large images.

For a service where the core value proposition is "convert HEIC/AVIF fast," that's a non-starter.

The solution: a separate container on Cloud Run.

The converter is itself a small Hono app (@hono/node-server) that runs on Node.js 22 with native Sharp:

FROM node:22-slim AS builder
# ... build stage ...

FROM node:22-slim
RUN apt-get update && apt-get install -y \
    libvips-dev \
    ffmpeg \
    ghostscript
# ...

Note ffmpeg and ghostscript are also installed — this handles video conversions and PDF operations respectively.

The conversion flow:

Worker receives /api/convert request
For images/audio: Worker fetches the file from R2, POSTs it to Cloud Run (/convert/direct), streams back the result
For videos (which can take minutes): Worker dispatches an async job via c.executionCtx.waitUntil(), Cloud Run pulls the file from R2 directly, converts, writes back to R2, then POSTs a callback to the Worker to update the D1 job record

Workers have a 30-second CPU time limit. waitUntil() extends this for background work, but video conversions can still exceed it. The async R2-based flow for video sidesteps this entirely.

Image quality defaults (from the actual code):

const DEFAULT_QUALITY: Record<string, number> = {
  jpg: 85,   // mozjpeg
  webp: 80,
  avif: 65,  // AVIF compresses aggressively; 65 looks good
  tiff: 80,
};

AVIF at quality 65 typically produces files 50–70% smaller than JPEG at equivalent perceptual quality. That compression ratio is why I focused on next-gen formats.

Cloud Run configuration: max-instances=1. This is intentional cost control during early stages. A single instance handles queue sequentially. As traffic grows this will increase, but starting at 1 means zero idle cost outside the free tier.

Storage: Cloudflare R2

All files — uploaded originals and converted outputs — live in R2 (quickconv-files bucket).

Why R2 over S3?

One reason: zero egress fees. S3 charges ~$0.09/GB for data transferred out. For a conversion service, every download is egress. R2 charges $0 for egress to the internet.

The math:

1,000 conversions/day × avg 2MB output = 2GB/day egress
S3: ~$5.40/month just for egress
R2: $0

Storage cost is $0.015/GB/month after the 10GB free tier. At current scale, I'm in the free tier.

24-hour auto-delete: Files are automatically expired after 24 hours. This is configured as an R2 lifecycle rule, not application-level deletion. It runs even if the API is down.

The FILE_EXPIRY_HOURS = 24 constant in the shared package is purely for setting the expiresAt field in D1 (for display purposes). The actual deletion is infrastructure-level.

Database: Cloudflare D1

D1 is Cloudflare's serverless SQLite. I use it for:

Job records (status, input/output R2 keys, timestamps)
Rate limit counters (daily conversions per clientHash)
User accounts (email, Stripe customer ID, plan)
Video conversion monthly counters

Why D1 and not Postgres/PlanetScale/Turso?

For a Workers-native app, D1 is the obvious choice: zero latency to bind, no connection pooling issues (SQLite has no connection limit), and it's free for the first 5M rows/month.

The schema is managed with Wrangler migrations:

npx wrangler d1 migrations apply quickconv-db --remote

SQLite's single-writer model is fine for this workload. Rate limit increments use INSERT OR REPLACE patterns that are safe under SQLite's serialized writes.

Payments: Stripe

Stripe handles all billing. The checkout flow: Workers creates a Stripe Checkout Session, redirects the user, Stripe POSTs to /api/webhook on completion, Worker updates the D1 user record with the plan.

Developer API

One thing I added recently that I'm excited about: a public /v1/convert endpoint for developers.

curl -X POST https://api.quickconv.cc/v1/convert \
  -H "Authorization: Bearer qc_YOUR_API_KEY" \
  -F "file=@photo.jpg" \
  -F "output_format=webp"

Developers get an API key from their account dashboard. The key is authenticated via middleware, rate-limited per plan, and the conversion hits the same Cloud Run backend. No separate infrastructure — the same Sharp container serves both the UI and the API.

This was about 2 days of work on top of the existing backend. The hard part (conversion, storage, rate limiting) was already done.

Monitoring: Sentry

Sentry is initialized in all three components:

Frontend (@sentry/nextjs) — captures unhandled errors and route transitions
API Workers (@sentry/cloudflare) — captures Worker exceptions with breadcrumbs per conversion
Converter (@sentry/node) — captures conversion failures with file size/format context

The converter adds structured breadcrumbs for every conversion:

addConversionBreadcrumb({
  conversionFormat: `${inputFormat}-to-${outputFormat}`,
  durationMs: Date.now() - startTime,
  fileSizeInput: inputBuffer.length,
  fileSizeOutput: result.size,
});

This makes it easy to diagnose which format pairs are slow or failing.

Cost Breakdown

Monthly costs at current (early) scale:

Service	Cost
Cloudflare Workers	$0 (free tier: 100K req/day)
Cloudflare Pages	$0 (static assets, unlimited)
Cloudflare R2	$0 (under 10GB free tier)
Cloudflare D1	$0 (under 5M rows free tier)
GCP Cloud Run	$0 (under ~180K vCPU-seconds free/month)
Domain (quickconv.cc)	~$1/month amortized
Sentry	$0 (free tier: 5K errors/month)
Total	~$1/month

The GCP free tier for Cloud Run is 180,000 vCPU-seconds per month. A typical image conversion takes ~0.5–2 seconds of CPU. That's roughly 90,000–360,000 conversions before I pay anything on Cloud Run.

When I exceed free tiers, the marginal cost is still low: Workers Paid plan is $5/month for 10M requests. R2 storage is $0.015/GB. Cloud Run is ~$0.024 per vCPU-hour.

Lessons Learned

1. Don't fight the platform. When I first designed the converter, I tried to shoehorn Sharp into a Worker via WASM. It took two days to discover AVIF encoding wasn't supported. Accepting that Workers can't run native binaries and reaching for Cloud Run took an afternoon. Know your runtime's constraints upfront.

2. Shared types are worth the monorepo overhead. The @quickconv/shared package contains types, format constants, and validation schemas used by both the API Worker and the converter container. Without it, I'd have duplicated ~500 lines and diverged them within a week.

3. Static export is underrated. The combination of Next.js static export + Cloudflare Pages is genuinely fast — Time to First Byte from edge nodes is under 50ms globally. For content that doesn't change per request, there's no reason to pay for server-side rendering.

4. R2 egress pricing changes the math entirely. If you're building anything where users download files, compare R2 vs S3 egress costs before assuming S3 is the default. For download-heavy workloads, R2 is often 5–10x cheaper.

5. waitUntil() is not a queue. Workers' executionCtx.waitUntil() lets you run background work after returning a response, but it still has limits (30-second CPU, subject to Workers runtime constraints). For video conversions that might run 5+ minutes, I moved to a true callback pattern: dispatch to Cloud Run, Cloud Run calls back when done.

What's Next

Format expansion: SVG → PNG, PDF → image batch
Quality comparison preview (side-by-side before/after slider)
More language support beyond ja/en

Try It

quickconv.cc — free tier is 10 conversions/day, no account required.

If you're building something that needs image conversion, the developer API is live. Free tier includes 100 conversions/month.

The stack is deliberately unsexy: Next.js, Hono, Sharp, SQLite. No Kubernetes, no microservices, no Kafka. It serves the use case, runs on almost nothing, and I can reason about the whole thing in my head. That feels like the right place to start.

Built with Next.js 15, Hono 4, Sharp 0.33, Cloudflare Workers/Pages/R2/D1, GCP Cloud Run, Stripe, Sentry.

DEV Community: quickconv

WebP vs AVIF vs HEIC: The Real-World Image Format Comparison (2026)

WebP vs AVIF vs HEIC: The Real-World Image Format Comparison (2026)

The Short Answer

WebP

AVIF

HEIC

Browser Support Deep Dive

Encoding Speed Comparison

Lossless Comparison

Transparency (Alpha Channel)

My Recommendations by Use Case

How to Convert

The Bottom Line

Claude Code on the Web: Why Your .env Vars Don't Reach the Setup Script (and How SessionStart Hook Fixes It)

TL;DR

Background

What I wanted to do

First attempt (failed)

Narrowing it down

Symptom 1: my echo output never showed up

Workaround: dump everything to a log file

Symptom 2: the cache trap

The result: every env var was empty

The clincher: the session shell has them

Root cause and fix

Root cause

Fix: move clone logic into a SessionStart hook

What about the setup script?

Verification

Gotchas summary

Closing

References

I Built an Image Conversion SaaS on (Almost) $0/Month — Here's the Full Stack

I Built an Image Conversion SaaS on (Almost) $0/Month — Here's the Full Stack

Architecture Overview

Frontend: Next.js with Static Export

API Layer: Hono on Cloudflare Workers

Conversion Engine: Sharp on GCP Cloud Run

Storage: Cloudflare R2

Database: Cloudflare D1

Payments: Stripe

Developer API

Monitoring: Sentry

Cost Breakdown

Lessons Learned

What's Next

Try It

Symptom 1: my `echo` output never showed up