Open-source project pages live or die by their screenshots. A crisp hero shot at the top of a README convinces a visitor in seconds; a page that takes forever to load loses them just as fast. The problem is that most screenshots start life as PNGs, and PNGs are heavy. A full-screen capture can easily run several megabytes, and a README with four or five of them becomes a slow page before anyone reads a word.
Converting those screenshots to WebP before you push is one of the cheapest performance wins a project page can get. Here is a practical pass you can run in a few minutes.
Audit what you actually have. Before converting anything, list the images your README references and check their sizes. Screenshots taken on retina displays are often twice as large as they need to be: a 2880-pixel-wide capture displayed at 800 pixels is carrying four times the pixels it shows. Resize to the display width first, then convert. Conversion alone cannot fix an image that is needlessly huge.
Convert screenshots, keep the originals. Screenshots compress well in WebP because they are mostly flat colors, text, and UI shapes — exactly the content WebP handles efficiently. Convert a copy, never the only original. Keep the PNG masters in a separate folder (or in the repo under a different path) so you can re-export if a design changes or a platform renders something oddly.
A browser-local converter works well here: you can png to webp right in the browser, with the files processed on your own device and nothing uploaded. That matters for screenshots that show unreleased features, internal dashboards, or customer data you should not be sending to a random conversion server.
Check the result where it will be seen. GitHub renders WebP in markdown images, and modern browsers all support it. Still, open the rendered README after the swap and actually look at every image: text should stay sharp, gradients should stay smooth, and any transparency should behave. If a particular screenshot looks worse — fine gradients and photographic screenshots are the usual suspects — keep that one as PNG. A mixed page is fine; the goal is a lighter page, not a pure format.
Watch the places people copy your images. README images get reused: forked, embedded in blog posts, pasted into docs. If downstream users hotlink your files, a WebP file is what they get, and that is fine for browsers. But if your images also feed a PDF export, a slide deck, or an email template, keep PNG versions available for those paths — some of those tools still do not handle WebP.
Make it part of the contribution habit. The real win is not a one-time conversion but a habit: every new screenshot gets resized and converted before it lands in the repo. Add a line to your contributing guide — "screenshots under 300 KB, WebP preferred" — and the page stays fast without anyone having to run a cleanup pass later.
Disclosure: I'm the developer of FileOnTap. The "resize first, convert a copy, check the rendered page" order is the real takeaway whichever tool you use.
Top comments (1)
Good point about resizing before converting. A 2880px retina capture shown at 800px is mostly wasted bytes no matter the format. I'd also add a quick look at the rendered README in dark mode, since flat-color UI screenshots sometimes get odd edges after compression.