Comparisons
WebP vs JPG for Google Ranking
WebP vs JPG for Google ranking is really a page-speed and user-experience question, not a direct ranking switch.
The short answer
If your audience and stack support it cleanly, WebP is usually the stronger default for many live website photos because it reduces payload size.
Where WebP helps and where JPG still makes sense
WebP often helps because it can deliver smaller files than JPG at comparable visual quality, especially in modern browser-based publishing workflows. JPG still makes sense where compatibility, simplicity, or older systems matter more than squeezing every possible byte out of the asset.
For ranking, neither extension wins by itself. What matters is whether the image workflow contributes to a faster and more usable page.
- WebP: often smaller for modern web delivery.
- JPG: still practical for broad compatibility and photo-focused legacy workflows.
Real examples
An article thumbnail library may become lighter site-wide after a switch from JPG to WebP. A legacy ecommerce upload path may still prefer JPG upstream even if the storefront uses modern delivery later. Some editorial teams keep JPG for certain workflows because the tooling is simpler, then optimize elsewhere.
How it affects SEO and page speed
Google rewards helpful, efficient pages, not a file extension in isolation. WebP often helps because it supports lighter pages.
Developer and workflow notes
Teams should choose the format rule that fits their actual stack rather than chasing format trends without implementation discipline.
Common mistakes to avoid
- Assuming WebP automatically improves rankings without improving the actual page experience.
- Switching to WebP but leaving the image dimensions oversized.
- Ignoring the editorial workflow and ending up with inconsistent media handling.
- Treating JPG as obsolete even where compatibility still matters.
The byte math: what WebP actually saves at each quality level
At matched visual quality, lossy WebP files run roughly 25 to 34 percent smaller than JPEG measured by SSIM. The gap widens as you lower quality. A 1600x1066 px photo saved as JPEG at quality 80 lands around 240 to 320 KB; the same image as WebP at quality 80 lands around 160 to 210 KB. At quality 75, WebP typically clears 150 KB while the JPEG sits near 220 KB. Lossless WebP beats PNG by about 26 percent, so a 24-bit screenshot that is 480 KB as PNG drops to roughly 350 KB as WebP without touching a pixel.
The quality slider does not map one to one between formats. WebP quality 75 looks closer to JPEG quality 82 because WebP uses VP8 block prediction instead of JPEG's 8x8 DCT, so do not copy your JPEG number across. For web photos, set WebP between 72 and 80; below 65 you get visible blocking on gradients like skies and skin. JPEG holds detail slightly better above quality 90, which is why archival masters and print sources stay JPEG or TIFF, but at that quality the file is 3 to 5 times larger than a quality-78 WebP and is the wrong choice for a live page.
This is the link to ranking. Largest Contentful Paint must hit 2.5 seconds or less to pass Core Web Vitals, and on article and product pages the LCP element is almost always the hero image. Cutting that hero from a 300 KB JPEG to a 190 KB WebP removes roughly 110 KB from the critical path, which on a throttled 4G connection at about 1.6 Mbps saves close to 550 ms of LCP. That margin is often the difference between a passing and failing field score.
Per-breakpoint export targets for a published page
Resize before you convert. A WebP exported at the wrong dimensions still ships every wasted pixel, and a 4000 px camera file scaled down by the browser is the single most common cause of a bloated page that otherwise uses the right format. Set the pixel dimensions to the largest box the image occupies in your layout, account for 2x retina where it matters, then convert. The Resize Image tool fixes dimensions first and the Compress Image tool hits a target weight after.
Use these concrete targets for a standard content site. Each lists the export width, the format, and a realistic WebP file-size ceiling:
- Article hero, full-bleed: 1600 px wide WebP at quality 78, under 200 KB. Serve a 1024 px variant under 120 KB to phones.
- In-body content image: 1200 px wide WebP at quality 75, under 130 KB.
- Blog thumbnail or card: 600 px wide WebP at quality 72, under 45 KB.
- Author avatar or small icon photo: 96x96 px WebP, under 8 KB.
- Open Graph social preview: 1200x630 px (1.91:1) JPEG or PNG at under 300 KB, because Facebook, LinkedIn, and X still re-encode and some scrapers skip WebP.
- Product gallery main image: 1500x1500 px (1:1) WebP at quality 80, under 220 KB; zoom source up to 2048 px under 400 KB.
Serving both formats without breaking older clients
WebP is supported in every current browser engine: Chrome and Android since 2014, Firefox since version 65, and Safari 14 and up on iOS and macOS since September 2020. In 2026 that covers more than 96 percent of global traffic, so a hard cutover is safe for most sites. The remaining risk is old in-app webviews and email clients, not real browsers.
When you need a guaranteed fallback, use the picture element rather than swapping the src in JavaScript. List the WebP source first and the JPEG inside the img tag: the browser picks the first type it understands and never downloads both. Set width and height attributes on the img so the layout reserves space and your Cumulative Layout Shift stays under 0.1. Add loading equals lazy to below-the-fold images, but never to the LCP hero, because lazy-loading the hero delays the very paint Google measures.
If you are weighing the next step, AVIF beats WebP by another 20 to 30 percent on file size and is supported in Chrome, Firefox, and Safari 16.4 and up. It encodes far slower and can soften fine text, so the practical 2026 stack is AVIF first, WebP as the broad fallback, JPEG last. Keep your original JPEG or PNG masters; WebP at quality 75 is a delivery format, and re-compressing an already-compressed WebP a second time stacks artifacts you cannot undo.
Tools that help
Once you have picked a format, finish the job in your browser: convert the file, resize it to the layout you actually need, and compress it to a realistic weight with the tools below.
