# 0.153.0 dropped PNG support?

**URL:** <https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410>\
**Category:** support\
**Created:** [December 20, 2025, 7:25am UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410 "2025-12-20T07:25:41Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![nekr0z](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/nekr0z/32/18320_2.png) [@nekr0z](https://discourse.gohugo.io/u/nekr0z)\
**Post date:** [December 20, 2025, 7:25am UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/1 "2025-12-20T07:25:41Z")

</div>

Where 0.152.2 works as expected, 0.153.0 fails with `image: unknown format` in an attempt to resize a PNG image. Is this a bug or a feature?

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [December 20, 2025, 10:16am UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/2 "2025-12-20T10:16:10Z")

</div>

Certainly not, we have lots of PNG tests and I have tested several sites with PNGs … But we have obviously gotten something wrong. To take WebP decoding in-house we needed to consolidate all decoding/encoding (Go’s setup gets initialised per format with a package import…

I will do a patch release later today increasing the WebP memory limit, and will try to pinpoint where I got it wrong re. PNG, but it would help a lot if you could provide some details as to what function that fails, or even better, point to a failing site on GitHub.

> <https://github.com/gohugoio/hugo/issues/14288>
>
> See https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [December 20, 2025, 11:10am UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/3 "2025-12-20T11:10:42Z")

</div>

OK, I have checked and double checked + added some more PNG tests, and I suspect this is something very specific. Maybe it isn’t a PNG file you’re trying to process and it happened to work before because, I don’t know.

---

<div class="post-metadata">

**Author:** ![irkode](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/irkode/32/26135_2.png) [@irkode](https://discourse.gohugo.io/u/irkode)\
**Post date:** [December 20, 2025, 12:09pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/4 "2025-12-20T12:09:07Z")

</div>

did the following test:

- created four images types: PNG, JPG, JPEG, WEBP
- copied each image by using all extensions
  - **actual file format** in CAPTIALS as filename
  - extension in lower case

```auto
JPEG.jpg
JPG.jpg
PNG.jpg
WEBP.jpg

```

for each I did `resize 100x` and `resize 100x webp`

- with 152.2 all images are resized without errors

- with 153.0 it fails for both cases if

> **Summary**
>
> ```plaintext
> WARN 1==== RESIZE ONLY ====
> WARN 2[resize 100x] OK : /images/JPEG.jpg
> WARN 3[resize 100x] OK : /images/JPG.jpg
> WARN 4[resize 100x] OK : /images/PNG.jpg
> WARN 5[resize 100x] OK : /images/WEBP.jpg
> WARN 6==== RESIZE and convert to WEBP ====
> WARN 7[resize 100x] OK : /images/JPEG.jpg
> WARN 8[resize 100x] OK : /images/JPG.jpg
> WARN 9[resize 100x] OK : /images/PNG.jpg
> WARN 10[resize 100x] OK : /images/WEBP.jpg
> WARN 11----------------------
> WARN 12==== RESIZE ONLY ====
> WARN 13[resize 100x] OK : /images/JPEG.jpg
> WARN 14[resize 100x] OK : /images/JPG.jpg
> WARN 15[resize 100x] OK : /images/PNG.jpg
> WARN 16[resize 100x] OK : /images/WEBP.jpg
> WARN 17==== RESIZE and convert to WEBP ====
> WARN 18[resize 100x] OK : /images/JPEG.jpg
> WARN 19[resize 100x] OK : /images/JPG.jpg
> WARN 20[resize 100x] OK : /images/PNG.jpg
> WARN 21[resize 100x] OK : /images/WEBP.jpg
> WARN 22----------------------
> WARN 23==== RESIZE ONLY ====
> WARN 24[resize 100x] OK : /images/JPEG.png
> WARN 25[resize 100x] OK : /images/JPG.png
> WARN 26[resize 100x] OK : /images/PNG.png
> WARN 27[resize 100x] OK : /images/WEBP.png
> WARN 28==== RESIZE and convert to WEBP ====
> WARN 29[resize 100x] OK : /images/JPEG.png
> WARN 30[resize 100x] OK : /images/JPG.png
> WARN 31[resize 100x] OK : /images/PNG.png
> WARN 32[resize 100x] OK : /images/WEBP.png
> WARN 33----------------------
> WARN 34==== RESIZE ONLY ====
> WARN 35[resize 100x] FAIL : /images/JPEG.webp
> WARN 36[resize 100x] FAIL : /images/JPG.webp
> WARN 37[resize 100x] FAIL : /images/PNG.webp
> WARN 38[resize 100x] OK : /images/WEBP.webp
> WARN 39==== RESIZE and convert to WEBP ====
> WARN 40[resize 100x] FAIL : /images/JPEG.webp
> WARN 41[resize 100x] FAIL : /images/JPG.webp
> WARN 42[resize 100x] FAIL : /images/PNG.webp
> WARN 43[resize 100x] OK : /images/WEBP.webp
> WARN 44----------------------
> 
> ```

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [December 20, 2025, 12:31pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/5 "2025-12-20T12:31:50Z")

</div>

OK; that I understand, when decoding an image:

- For WebP we currently only use the MediaType derived from the extension.
- For PNG and JPEG we delegate to Go’s stdlib – which looks at the file header.
- I originally did the first approach for both, but testing it on some sites I found that it’s very common to name JPEG files as PNG and vice versa …

OK, I can certainly adjust the logic to handle this. Thanks for the input.

---

<div class="post-metadata">

**Author:** ![irkode](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/irkode/32/26135_2.png) [@irkode](https://discourse.gohugo.io/u/irkode)\
**Post date:** [December 20, 2025, 12:36pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/6 "2025-12-20T12:36:35Z")

</div>

> [@nekr0z](#):
>
> attempt to resize a PNG image

would be really good to elaborate on that to see if that’s a known one:

- full code of the resize call
- full image file name
- _real_ image format

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [December 20, 2025, 12:41pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/7 "2025-12-20T12:41:28Z")

</div>

> [@bep](#):
>
> OK, I can certainly adjust the logic to handle this. Thanks for the input.

But then again, why do you name a PNG with webp extension …? I adjusted the PNG/JPEG to reduce noise in the release, but this sounds like something that should be fixed by renaming the file.You would get the same issue if you rename e.g. a JPEG file to \*.bmp …

---

<div class="post-metadata">

**Author:** ![chrillek](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/chrillek/32/19797_2.png) [@chrillek](https://discourse.gohugo.io/u/chrillek)\
**Post date:** [December 20, 2025, 1:02pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/8 "2025-12-20T13:02:06Z")

</div>

> [@bep](#):
>
> But then again, why do you name a PNG with webp extension …?

Mishap? Or just someone who doesn’t give a damn about file extensions, hoping that software will inspect the contents? There’s (IMO, of course) nothing wrong with naming a file `my-lovely-webp.img` or even `that-other-png` without any extension.

File extensions are largely an inheritance from DOS, where there were no mechanisms to figure out the content. Since then, we’ve got the `files` command, MIME types, and UTIs. And even (Open)VMS didn’t force a meaning on the extension: [File extension - VSI OpenVMS Wiki](https://wiki.vmssoftware.com/File_extension)

---

<div class="post-metadata">

**Author:** ![nekr0z](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/nekr0z/32/18320_2.png) [@nekr0z](https://discourse.gohugo.io/u/nekr0z)\
**Post date:** [December 20, 2025, 1:07pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/9 "2025-12-20T13:07:44Z")

</div>

Indeed, the image itself, upon close inspection, turned out to be WebP (I have no idea how it came to be this way with the wrong extension).

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [December 20, 2025, 1:08pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/10 "2025-12-20T13:08:32Z")

</div>

> [@chrillek](#):
>
> nothing wrong with naming a file `my-lovely-webp.img` or even `that-other-png` without any extension.

If it fails to be understood by the receiving software, would you still claim the above?

Sniffing the content to resolve the MediaType is a gazillion times slower than just using the extension.

---

<div class="post-metadata">

**Author:** ![chrillek](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/chrillek/32/19797_2.png) [@chrillek](https://discourse.gohugo.io/u/chrillek)\
**Post date:** [December 20, 2025, 1:34pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/11 "2025-12-20T13:34:44Z")

</div>

> [@bep](#):
>
> Sniffing the content to resolve the MediaType is a gazillion times slower than just using the extension.

Yes. OTOH, software might not want to rely solely on the extension. Checking it and _then_ verifying if the extension matches the content might be an acceptable slowdown given that the content must be read anyway. And if the two do not match, the software can raise an informative error.

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [December 20, 2025, 5:14pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/12 "2025-12-20T17:14:23Z")

</div>

> [@chrillek](#):
>
> Checking it and _then_ verifying if the extension matches the content might be an acceptable slowdown

To be clear, that’s also what we do in Hugo’s WebP decoder. But we use Go stdlib’s for the others (PNG, JPEG etc.) and the way they wire that up (global state, package initialisers) made it hard to create an elegant Decode method that had a fallback to e.g. PNG for foo.webp. I assumed this was an OK trade off to get WebP animation support and fix the dull color/low contrast issue … But I guess some prefer to name their files in confusing ways …

OK, well, in Hugo v0.153.1 I added a fallback in the decoder to hopefully make everyone happy.

Happy holidays all!

---

<div class="post-metadata">

**Author:** ![system](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/system/32/1_2.png) [@system](https://discourse.gohugo.io/u/system)\
**Post date:** [December 22, 2025, 5:15pm UTC](https://discourse.gohugo.io/t/0-153-0-dropped-png-support/56410/13 "2025-12-22T17:15:16Z")

</div>

Closed on December 22, 2025, 5:15pm UTC

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.