How to convert JPG to WebP on iPhone
Converting to WebP on an iPhone is oddly hard, and the reason is technical rather than commercial: Apple's imaging stack can decode WebP but cannot encode it. Most iPhone converters therefore offer WebP as an input only.
Why this conversion is rare on iOS
iOS's ImageIO framework — the thing almost every image app on the App Store ultimately calls — has read support for WebP (since iOS 14) and no write support. There is no CGImageDestination for WebP. An app that only uses Apple's frameworks physically cannot produce a WebP file, which is why you keep finding converters that happily take WebP in and refuse to give it back out.
Convexy bundles libwebp, Google's own reference encoder, and routes WebP output through it instead of through ImageIO. That is the only way to do this on iOS, and it is a real difference rather than a marketing one — you can verify it by checking that the output file starts with the RIFF/WEBP magic bytes.
What WebP actually gains you
WebP's lossy mode is VP8 intra-frame coding. At the same visual quality it lands roughly 25–35% smaller than JPG — the reason essentially the entire web now serves it. It also supports an alpha channel and animation, neither of which JPG can do.
The obvious use case: you are putting images on a website, into a web app, or anywhere page weight and Core Web Vitals matter. Every major browser has supported WebP for years. The less obvious one: you are simply out of storage and want a photo library that is a third smaller.
You are re-encoding a lossy image with another lossy codec. The JPG already discarded detail; WebP will now discard more, and it cannot recover what JPG lost. The saving is real but the loss is cumulative. If you have access to the original (a RAW, a PNG, a HEIC straight from the camera), encode WebP from that instead — one lossy generation is always better than two.
The quality slider does something unusual here
For JPG, HEIC and AVIF, Convexy's quality slider maps to the codec's quality factor and every setting is lossy. WebP is different, because WebP has a genuinely lossless mode:
- Below 100%: lossy VP8 encoding at that quality factor. The colour planes degrade; the alpha channel is still stored losslessly.
- At 100%: Convexy switches libwebp into its lossless encoder rather than merely asking for quality 100. You get a mathematically exact copy of the input pixels, usually still smaller than the equivalent PNG.
So a JPG converted to WebP at 100% adds no further loss at all — it just cannot undo the loss the JPG already baked in.
Before you convert your whole library: WebP is universal on the web and patchy off it. Some desktop software, some print services and some upload forms still reject it. It is the right format for the web and a slightly risky one as your only archive copy.
Nothing is uploaded
Web-based WebP converters have to receive your image on a server to encode it. Convexy encodes on the phone with the bundled libwebp — no upload, no account, no network call at all. It works in Airplane Mode.
How to do it
-
Pick the JPG
Tap Browse files, choose from Photos, or share an image into Convexy. Select several at once to batch them — useful when you are preparing a whole set of images for a site.
-
Choose WebP
WebP appears in the list of formats a JPG can become. Convexy writes it through the bundled libwebp encoder rather than Apple's ImageIO, which has no WebP writer.
-
Choose lossy or lossless with the quality slider
Anything below 100% is lossy VP8 at that quality factor. Set it to 100% and libwebp switches to its lossless encoder, adding no further loss to the pixels it is given.
-
Resize if this is for the web
The single biggest win for page weight is usually not the codec — it is not shipping a 4000px image into a 800px slot. Set a maximum dimension in Options.
-
Convert, then save or share
The result screen shows the size drop. Save to Files, rename it, or share it straight into whatever you are publishing with.
Common questions
Why can't most iPhone apps convert to WebP?
Because Apple's ImageIO framework has a WebP decoder but no WebP encoder. Apps built purely on Apple's frameworks can read WebP and cannot write it — there is no API to call. The only way around it is to ship a third-party encoder, such as Google's libwebp, inside the app. Convexy does exactly that.
How much smaller is WebP than JPG?
Typically 25–35% smaller at the same perceived quality, though it depends heavily on the image. Photographic content with lots of fine detail sees less benefit; smoother images see more. Do not expect a magic 10x — anyone promising that is talking about resizing, not re-encoding.
Does converting JPG to WebP lose quality?
At any quality setting below 100%, yes — it is a second lossy encode on top of the JPG's existing loss. At 100% Convexy uses libwebp's lossless mode, which adds no further loss whatsoever, though the file is then considerably bigger. Either way, WebP cannot restore what the JPG already threw away.
Can I convert WebP back to JPG later?
Yes, and Convexy does that too. But each lossy round trip degrades the image a little further. Treat WebP as an output format for delivery, and keep your original JPG (or better, the original camera file) as the master copy.
Is WebP safe to use everywhere?
On the web, yes — every current browser supports it. Off the web it is patchier: some desktop applications, print services and upload forms still refuse it. Use WebP where you control the destination, and keep something more boring for anything you hand to a system you do not control.
Does WebP support transparency like PNG?
Yes, WebP has a full 8-bit alpha channel in both its lossy and lossless modes — and in Convexy the alpha is always stored losslessly, even when the colour planes are lossy. That makes it a strong replacement for PNG on the web. A JPG has no transparency to carry over, but a PNG converted to WebP keeps its alpha intact.