--- title: Why Tiny JPEGs Look Different in Chrome | daily.dev description: An investigation into why a small JPEG icon rendered differently in Chrome versus Firefox reveals a clever decoding optimization. Chrome's rendering engine... canonical: https://daily.dev/posts/why-tiny-jpegs-look-different-in-chrome-68fy1ywqj twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Why Tiny JPEGs Look Different in Chrome | daily.dev og:description: An investigation into why a small JPEG icon rendered differently in Chrome versus Firefox reveals a clever decoding optimization. Chrome's rendering engine... og:url: https://daily.dev/posts/why-tiny-jpegs-look-different-in-chrome-68fy1ywqj og:image: https://api.daily.dev/og/posts/68fy1YWqJ.png og:image:alt: Why Tiny JPEGs Look Different in Chrome og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why Tiny JPEGs Look Different in Chrome **[Hacker News](https://daily.dev/sources/hn)** · 6 min read · 2 upvotes · 1 comments ## Summary An investigation into why a small JPEG icon rendered differently in Chrome versus Firefox reveals a clever decoding optimization. Chrome's rendering engine Skia uses libjpeg-turbo's partial IDCT scaling, which decodes only low-frequency coefficients when the target display size is small enough, skipping full decompression before downscaling. This explains why tiny JPEGs can look blockier or thicker in Chrome, and the practical takeaway is to avoid JPEG for icons and use SVG or PNG instead since JPEG's optimizations are tuned for photographic content, not sharp edges. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does a small JPEG icon look different in Chrome compared to Firefox? Chrome delegates JPEG decoding to Skia, which uses libjpeg-turbo's partial IDCT scaling to decode only low-frequency DCT coefficients when the target render size is small enough. For an icon rendered at roughly one-eighth scale, only the constant component (flat color) survives, so edge softening and gradients from higher-frequency coefficients are dropped, making the image look flatter or thicker than a fully decompressed-then-scaled version. _Debugging subtle rendering differences across browsers is easier when daily.dev surfaces deep dives like Skia's JPEG decoding path._ ### What is partial IDCT scaling in JPEG decoding? Partial IDCT scaling is a technique that decodes a JPEG directly at a reduced size by using only the coefficients needed for that scale, skipping high-frequency data, instead of fully decompressing the image and then downscaling it. It works for any fraction with a denominator of 8, since JPEG stores data in 8x8 blocks transformed via a discrete cosine transform (DCT), and libjpeg-turbo implements it for both downscaling and upscaling. _Understanding compression internals like this helps developers choose the right image format, something daily.dev keeps engineers current on._ ### Should I use JPEG for small icons? No, JPEG is a poor choice for icons and similar small graphics because its compression and decoding optimizations are built around photographic content perception, not sharp small-scale graphics. Because decoders like libjpeg-turbo skip high-frequency detail when rendering JPEGs at small sizes, icons can look flatter or thicker than intended; using SVG instead avoids this rendering inconsistency across browsers. _Picking the right image format for icons is a recurring decision daily.dev helps developers get right the first time._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 46 comments across hackernews, lobsters (as of 2026-09-13). **TL;DR:** Commenters found the technical explanation compelling and dug further into the details, while also debating whether the real culprit is the partial IDCT trick, differing browser scaling algorithms, or simply using oversized/wrong image formats for tiny icons. **Sentiment:** 45% positive · 40% mixed · 15% skeptical **The case for** - Several found the writeup genuinely illuminating, prompting them to share related bug reports and deeper technical context (e.g. Firefox's own downscale-during-decode approach). - One commenter noted the explanation matched an obscure rendering bug they'd previously encountered with a vendor's JPEGs. **The pushback** - Some argued the post overstates IDCT scaling's role, attributing most of the visual difference to Chrome vs Firefox using different (blur vs. ringing) scaling algorithms instead. - Multiple people pushed back that the real lesson is simpler: don't use oversized images (of any format) for tiny icons, since even PNGs at the wrong resolution can look bad. - One commenter disputed that PNGs can be partially decoded the way JPEGs can, questioning an anecdote about PNG icon issues. - A few noted browsers generally don't use state-of-the-art downscaling algorithms since they prioritize speed over quality, so relying on browser scaling is inherently risky. **By community** - hackernews (mixed): Detailed technical back-and-forth mixing appreciation for the investigation with pushback on the exact root cause and practical alternatives. - lobsters (mixed): The single comment agrees with the post's conclusion but adds that the real issue is using oversized images for tiny renders. **Hottest debate:** Whether the blockiness is mainly caused by libjpeg-turbo's partial IDCT scaling or simply by Chrome and Firefox using different image-scaling algorithms. **Open questions** - How exactly does Firefox's rendering pipeline handle downscaling internally, since no one in the thread was fully certain? - Will AVIF/WebP ever fully replace JPEG for this kind of use case, or will adoption stall like IPv6? **Highlights** > Firefox doesn't decode the image into a full-resolution buffer and then downscale either, instead it does a streaming decode and applies downscaling on the fly. They call it downscale-during-decode[0]. I guess it doesn't do partial decoding of the 8x8 blocks though. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1045926 > — [the8472 on hackernews](https://news.ycombinator.com/item?id=49273314) > I'm far from an image rendering expert myself, but I don't think there is a single root cause here. I don't doubt the partial decoding would affect the final result just as the scaling algorithm itself, so in the end it's going to be a combination of it all. The reason I believe the scaling algorithm is contributing more in your particular example, is because it looks almost exactly like a classic B/W comparison between a sharp ringing heavy algorithm and a more blurry one. For reference here is a quick comparison between Lanczos/Bilinear I threw together: https://twinlens.app/compare?share=40973d84a174 It would be interesting to see how your example would look if you used colors instead, where the ringing artifacts become a lot more obvious. Like this one: https://twinlens.app/compare?share=8fb890a5820e > — [debazel on hackernews · 1 comments](https://news.ycombinator.com/item?id=49274848) > Wow, this explains an issue I ran into for images from a certain vendor when we used idct scaling for the same reason: Some encoders (and a meaningful share of JPEGs in the wild) leave zeros or garbage in the unused rows/columns of the trailing MCU. At full-size decode those samples are cropped away, but IDCT scaling mixes them into neighboring output pixels and the artifacts become visible. See https://crbug.com/890745 and https://github.com/libjpeg-turbo/libjpeg-turbo/issues/297 In our particular case we were able to just crop out the edges and it was worth the tradeoff > — [adzm on hackernews](https://news.ycombinator.com/item?id=49276975) > I don't think it's possible to partially decode/render a PNG in a way similar to JPEG. The only exception I can think of is adam7 interlacing, which _does_ store the initial pass as 8x8 blocks, but I'm pretty sure PNGs with adam7 are rare in practice because they do result in larger files. > — [polpo on hackernews · 1 comments](https://news.ycombinator.com/item?id=49275419) > > Really, the moral here is that you should not use JPEG for icons and the like. … and maybe don’t use a big image to render 15x15 pixels. > — [m\_eiman on lobsters · 1 points](https://lobste.rs/s/xwo03g/why_tiny_jpegs_look_different_chrome#c_s8msde) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49272549) · 196 points · 45 comments - [lobsters](https://lobste.rs/s/xwo03g/why_tiny_jpegs_look_different_chrome) · 3 points · 1 comments ## Community discussion Top comments from developers on daily.dev. **@rizzdev** · 0 upvotes > Partial IDCT scaling is why tiny JPEG icons look blockier. SVG or PNG for that size ## Similar posts on daily.dev - [Regressive JPEGs: \(Maurycy's blog\)](https://daily.dev/posts/regressive-jpegs-maurycy-s-blog--sr9gxaz14) · Hacker News · 2 upvotes · 0 comments - [Opening this PNG in Chrome shows a different image than in Safari or any desktop app](https://daily.dev/posts/opening-this-png-in-chrome-shows-a-different-image-than-in-safari-or-any-desktop-app-xmisatnuv) · Lobsters · 3 upvotes · 0 comments - [Google rekindles relationship with jilted JPEG XL](https://daily.dev/posts/google-rekindles-relationship-with-jilted-jpeg-xl-icsnizefr) · The Register · 3 upvotes · 0 comments - [Loading Smarter: SVG vs. Raster Loaders in Modern Web Design](https://daily.dev/posts/loading-smarter-svg-vs-raster-loaders-in-modern-web-design-6vluk92ar) · CSS-Tricks · 2 upvotes · 0 comments --- Tags: [#webdev](https://daily.dev/tags/webdev), [#google-chrome](https://daily.dev/tags/google-chrome), [#image-processing](https://daily.dev/tags/image-processing) [View this post on daily.dev](https://daily.dev/posts/why-tiny-jpegs-look-different-in-chrome-68fy1ywqj) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Why Tiny JPEGs Look Different in Chrome","url":"https://daily.dev/posts/why-tiny-jpegs-look-different-in-chrome-68fy1ywqj","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/why-tiny-jpegs-look-different-in-chrome-68fy1ywqj"},"datePublished":"2026-08-12T14:49:19.663Z","dateModified":"2026-09-13T18:55:22.568Z","description":"An investigation into why a small JPEG icon rendered differently in Chrome versus Firefox reveals a clever decoding optimization. Chrome's rendering engine...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3d14e6085c3a0b5c0b08ae0ca34bc8a0?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3d14e6085c3a0b5c0b08ae0ca34bc8a0?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/why-tiny-jpegs-look-different-in-chrome-68fy1ywqj","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"webdev,google-chrome,image-processing","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Why Tiny JPEGs Look Different in Chrome"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/why-tiny-jpegs-look-different-in-chrome-68fy1ywqj","comment":[{"@type":"Comment","text":"Partial IDCT scaling is why tiny JPEG icons look blockier. SVG or PNG for that size","datePublished":"2026-08-13T06:49:36.909Z","url":"https://daily.dev/posts/68fy1YWqJ#c-hXmJqHsLX","author":{"@type":"Person","name":"Andrew","url":"https://daily.dev/rizzdev","image":"https://media.daily.dev/image/upload/s--35vRfXAA--/f_auto/v1785413727/avatars/avatar_fQ7ttCKtPuu6tDvcgQXv5?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/why-tiny-jpegs-look-different-in-chrome-68fy1ywqj#faq","mainEntity":[{"@type":"Question","name":"Why does a small JPEG icon look different in Chrome compared to Firefox?","acceptedAnswer":{"@type":"Answer","text":"Chrome delegates JPEG decoding to Skia, which uses libjpeg-turbo's partial IDCT scaling to decode only low-frequency DCT coefficients when the target render size is small enough. For an icon rendered at roughly one-eighth scale, only the constant component (flat color) survives, so edge softening and gradients from higher-frequency coefficients are dropped, making the image look flatter or thicker than a fully decompressed-then-scaled version. Debugging subtle rendering differences across browsers is easier when daily.dev surfaces deep dives like Skia's JPEG decoding path."}},{"@type":"Question","name":"What is partial IDCT scaling in JPEG decoding?","acceptedAnswer":{"@type":"Answer","text":"Partial IDCT scaling is a technique that decodes a JPEG directly at a reduced size by using only the coefficients needed for that scale, skipping high-frequency data, instead of fully decompressing the image and then downscaling it. It works for any fraction with a denominator of 8, since JPEG stores data in 8x8 blocks transformed via a discrete cosine transform (DCT), and libjpeg-turbo implements it for both downscaling and upscaling. Understanding compression internals like this helps developers choose the right image format, something daily.dev keeps engineers current on."}},{"@type":"Question","name":"Should I use JPEG for small icons?","acceptedAnswer":{"@type":"Answer","text":"No, JPEG is a poor choice for icons and similar small graphics because its compression and decoding optimizations are built around photographic content perception, not sharp small-scale graphics. Because decoders like libjpeg-turbo skip high-frequency detail when rendering JPEGs at small sizes, icons can look flatter or thicker than intended; using SVG instead avoids this rendering inconsistency across browsers. Picking the right image format for icons is a recurring decision daily.dev helps developers get right the first time."}}]} ```