WebP Hosting

WebP earns its place because it's typically 25-35% smaller than JPEG or PNG at matched quality, with both lossy and lossless modes plus alpha transparency — real bytes saved on every page view. But hosting it badly throws the win away. Serve a .webp from a misconfigured origin that returns application/octet-stream or text/plain and some browsers refuse to treat it as an image; serve it without edge caching and you've traded a smaller file for a slower origin round-trip. files.link hosts pre-optimized WebP on a global CDN with the correct image/webp content-type, so <img>, <picture>, CSS background-image, and srcset all just work, delivered from the nearest edge.

The deliberate scope here: files.link is storage plus CDN, not an optimization engine. It does not transcode PNG to WebP or negotiate formats from a URL parameter — it serves the exact bytes you upload. You bring your own pipeline, which is a feature if you want deterministic output and zero per-transform metering. Convert at build or upload time with Sharp — await sharp(input).webp({ quality: 80 }).toBuffer() — or the cwebp CLI — cwebp -q 80 photo.png -o photo.webp — then upload via the three REST calls (POST /v1/files/{folderId} → PUT the presigned URL → POST /v1/files/confirm-upload with {ids:[...]}).

For responsive images, generate the few widths your layout uses and reference them with srcset: <img src="hero-800.webp" srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w" sizes="(max-width:600px) 100vw, 50vw" alt="...">. For broad fallback, wrap WebP in a <picture> with a JPEG source — <picture><source srcset="photo.webp" type="image/webp"><img src="photo.jpg" alt="..."></picture> — though every current browser (Chrome, Firefox, Edge, Safari 14+) supports WebP natively, so fallback is mostly legacy insurance.

Because the CDN serves what you upload, your build determines quality and size precisely, and there's no surprise transform bill the way URL-driven services (Cloudinary, Cloudflare Images) can produce when derived URLs multiply. Billing is prepaid credits against storage and delivery, so a heavily-viewed image costs predictable bandwidth. If you also need AVIF, the same pattern applies — encode it yourself, upload it, and offer it as an additional <source type="image/avif"> ahead of WebP in your <picture>. files.link will serve any of these formats with the right content-type; the optimization decisions stay in your hands, where they're cheapest to control.