Prepare images for your website the right way
One image in, a production-ready set out: multiple responsive widths in WebP with JPG or PNG fallbacks, zipped up alongside copy-paste <picture> markup and a Next.js example — generated locally in your browser.
Comma-separated. Widths larger than the source are skipped — upscaling wastes bytes.
or drag & drop an image here, or paste from your clipboard
Use your largest master image — PNG, JPG, WebP, TIFF and more.
Your images are processed on your device and are not uploaded to PNGful.
How it works
- 1
Add your image
Drop in the full-resolution original — the largest version you have. Everything is processed on your device.
- 2
Pick your widths and formats
The default 320–1920 px range suits most layouts. Widths larger than your source are skipped automatically, since upscaling only wastes bytes.
- 3
Review the generated set
See every file with its dimensions and size — WebP versions plus a JPG or PNG fallback at each width.
- 4
Download the ZIP and copy the markup
Grab all files as one ZIP, then paste the generated <picture>/srcset markup or the Next.js Image example straight into your project.
Common uses
- Hero and banner images that dominate page weight
- Product photos for stores without an image CDN
- Blog post images on static-site generators
- Portfolio and photography sites that must stay sharp and fast
- Improving Core Web Vitals scores on an existing site
- Preparing assets for a hand-coded site with no build pipeline
srcset, sizes, and why layout shift matters
A srcset lists the same image at several widths and lets the browser pick the smallest one that still looks sharp for the visitor's screen — a phone downloads the 480 px file, a desktop the 1280 px one. The sizes attribute tells the browser how wide the image will render so it can make that choice before CSS loads. Wrapping it all in a <picture> element adds format negotiation: browsers that understand WebP take it, everything else falls back to JPG or PNG.
Setting explicit width and height attributes is just as important as the file sizes. They let the browser reserve the image's space before it downloads, so the page doesn't jump as images arrive. That jumping is Cumulative Layout Shift (CLS), one of Google's Core Web Vitals — and the generated markup includes the attributes so you don't have to remember them.
The Next.js example uses the framework's Image component with width and height set, which handles the srcset generation and space reservation for you at render time while still benefiting from the pre-optimized files.
Good to know
- Widths larger than your source image are skipped rather than upscaled — upscaling adds bytes without adding detail. Start from the largest original you have.
- WebP encoding uses your browser's encoder, so output size can differ slightly between browsers; AVIF output isn't generated because encoding support is still inconsistent.
- The generated sizes attribute is a sensible default — adjust it to match your actual CSS layout for optimal file selection.
- For sites with hundreds of images, a build-time pipeline or image CDN automates this better; this tool is ideal for the handful of images that matter most.
Your images stay private
Your images are processed on your device and are not uploaded to PNGful.All processing happens locally using your browser's own image engine — there is no upload step, no server-side queue, and nothing to delete afterwards. Read more in our privacy policy.
Frequently asked questions
Which widths should I generate?
The default 320–1920 px range covers phones through large desktops and is right for full-width images. If an image never renders wider than, say, 800 px in your layout, cap the range there — at roughly 2x its largest displayed size to stay sharp on high-density screens.
Why do width and height attributes matter?
They let the browser compute the image's aspect ratio and reserve its space before the file downloads. Without them, content jumps down as each image loads — that's Cumulative Layout Shift, which frustrates users and hurts your Core Web Vitals. The generated markup includes both attributes on every example.
Do I still need JPG or PNG fallbacks for WebP?
Mostly for insurance. Current browsers all decode WebP, but older browser versions, some embedded webviews, and tools that scrape or email your pages may not. The <picture> element makes the fallback free: capable browsers never download it, others get a working image instead of a broken one.
How many files does this generate?
Two per width — a WebP and a fallback. The default six widths produce up to twelve files, fewer if your source is smaller than some target widths, since those are skipped. Each file is named with its width so the generated srcset references line up exactly.
Is my image uploaded for processing?
No. Resizing, encoding and ZIP packaging all run in your browser. Your original never leaves your device.
Was this tool helpful?