It seems hugo server cannot serve SVGZ images. The proposed solution is impractical for me since I use hugo to generate a site with hundreds of thousands generated SVG images. I wouldn’t want to resort to first generating SVG images, testing the site with hugo server and then applying sed-replace and compressing the SVG images.
What’s the reason Hugo server can’t serve ready made SVGZ files? Those are just static image files that doesn’t require any transcoding etc. from hugo side?
Without going into dept, as you sure that that’s HUGO fault?
SVGZ Compatibility is limited to Google Chrome and Opera Browses.
You can serve in code whatever you like, but it is displayed correctly or not depending on the end-user browser. Like was with WebP years back.
Could you clarify the meaning “Hugo can’t serve SVGZ files”, as I may misunderstand this?
Hugo server is generally just used for development. There’s nothing to stop your deploying a built site with compressed svg.
Or, just use .svg?
except i misunderstood, you want serve .svgz file extension correctly as an svg image. @/bep reply to your linked thread above how to add/modify custom mediatypes.
you just need to add svgz as extras suffixes on mediatypes config. This is example in config.yaml
mediaTypes:
image/svg+xml:
suffixes:
- svg
- svgz
I tested using both object and img and it displayed in browser (Google Chrome)
<object data="../sample.svgz" width="480" height="360" type="image/svg+xml"></object>
<img src="../sample.svgz">
sample svgz file: https://www.w3.org/Graphics/SVG/Test/20110816/svg/conform-viewers-01-t.svgz
from this page: SVG 1.1 2nd Edition Test (svgweb): conform-viewers-01-t.svgz
Hi all,
First big thanks for everyone trying to help me 
I want hugo server to serve readily-generated SVGZ images as such to the browser and leave it to the browser to uncompress it and render the image.
I have (tried) to add mediaTypes to the site’s config.toml. I can see the generated site has correct image links and SVGZ image files, but (so far) hugo server doesn’t serve those correctly.
Since this is supposed to work (@pamubay ’s answer), I will debug my setup once I get back to my computer.
you can use different tools to generate svg.gz (zopfli) or svg.br (brotli) files,where most browsers will accept it.
I redirect svg files to the compressed version, if the browser can handle it. In my case with apache. This enables the function with all browsers.
The both named tools are from google, you can search for it.
OK, I think I was wrong. I could not get Chrome, Edge or Firefox to render SVGZ images properly even the images were 100% OK (opened fine with InkScape. I made a test page on GH Pages and none of the browsers rendered it OK even though the HTTP headers seemed all fine:
HTTP/2 200 OK
server: GitHub.com
content-type: image/svg+xml
x-origin-cache: HIT
last-modified: Thu, 05 Jan 2023 23:15:15 GMT
access-control-allow-origin: *
etag: W/"63b75a03-9c9"
expires: Thu, 05 Jan 2023 23:38:33 GMT
cache-control: max-age=600
content-encoding: gzip
x-proxy-cache: MISS
x-github-request-id: A17A:3BCD:FA4BFE:104EED7:63B75D20
accept-ranges: bytes
date: Thu, 05 Jan 2023 23:48:42 GMT
via: 1.1 varnish
age: 0
x-served-by: cache-hel1410033-HEL
x-cache: HIT
x-cache-hits: 2
x-timer: S1672962523.984268,VS0,VE1
vary: Accept-Encoding
x-fastly-request-id: e42460ae234aeee4d059067480d2385b80136ac0
content-length: 2533
X-Firefox-Spdy: h2
Initially I also used the test page found by @pamubay , but closer inspection shows the file is actually a SVG, not gzip-compressed SVGZ, file:
% wget -q https://www.w3.org/Graphics/SVG/Test/20110816/svg/conform-viewers-01-t.svgz
% file conform-viewers-01-t.svgz
conform-viewers-01-t.svgz: SVG Scalable Vector Graphics image
% head conform-viewers-01-t.svgz
<svg version="1.1" baseProfile="tiny" id="svg-root"
width="100%" height="100%" viewBox="0 0 480 360"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<!--======================================================================-->
<!--= SVG 1.1 2nd Edition Test Case =-->
<!--======================================================================-->
<!--= Copyright 2009 World Wide Web Consortium, (Massachusetts =-->
<!--= Institute of Technology, European Research Consortium for =-->
<!--= Informatics and Mathematics (ERCIM), Keio University). =-->
<!--= All Rights Reserved. =-->
Therefore, nevermind.
as explained by @Jylpah above, the svgz sample used in the test is not a svgz, actually just plain svg with svgz extension.
I opened the sample file with Inkscape an re-exported as Plain Compressed SVG (.svgz), after re-export, the file info:
file ./sample-compressed.svgz
./sample-compressed.svgz: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT), original size modulo 2^32 13794
CMIIW, compressed svg is part if SVG 2.0 draft specification, not even shipped in chrome?
https://chromestatus.com/feature/5760616295825408
https://svgwg.org/svg2-draft/single-page.html#conform-ConformingSVGServers
Thank you @pamubay. This clarified it all. I need to stick with SVG since the browser support is not there.
I rushed into conclusion SVGZ would be widely supported based on the “bit misleading” W3C test page that turned out to be something different I assumed it to be. SVGZ would have been a great way to push my repo size below GH Pages 10GB hard limit. Now I just need to cut down the content history to fit into GH Pages limits.
Big thanks Hugo community! You guys are awesome.
I am still confused of this. The web is full of references to the very same problem 10 years ago and then the solution was to add the content-encoding: gzip header to server side config. GH Pages has that header and none of the browsers support this.
It seems .svgz support is something that was supported, but the support has been dropped from the browsers since (see the 3rd link below).
Well just tried add custom server response header for svgz file extension, and it does work 
.
I tested both on Google Chrome and Firefox, both display the svgz via img and object.
The extra config:
# config.toml
[server]
[[server.headers]]
for = '*.svgz'
[server.headers.values]
Content-Encoding = 'gzip'
Vary = 'Accept-Encoding'
[mediaTypes."image/svg+xml"]
suffixes = ["svg","svgz"]
But here i made test repo:
Hugo Server Response config docs:
@pamubay deep respect for your stubbornness 
Your repo works for me too and I realized what causes the error: a missing Content-Type: charset=utf-8 response header.
Your demo 
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Encoding: gzip
Content-Type: image/svg+xml; charset=utf-8
Last-Modified: Fri, 06 Jan 2023 11:49:44 GMT
Vary: Accept-Encoding
Date: Fri, 06 Jan 2023 11:52:30 GMT
Transfer-Encoding: chunked
Github Pages 
HTTP/2 200 OK
server: GitHub.com
content-type: image/svg+xml
x-origin-cache: HIT
last-modified: Thu, 05 Jan 2023 23:15:15 GMT
access-control-allow-origin: *
etag: W/"63b75a03-9c9"
expires: Thu, 05 Jan 2023 23:38:33 GMT
cache-control: max-age=600
content-encoding: gzip
Notice the missing Content-Type: charset=utf-8 on the GH Pages example
I tested my own image on your test repo and it worked fine. I try to figure out why the charset is set wrong on my GH Pages site.
EDIT
Initially I had the SVG- files encoding set wrong by the content generator (R’s knitr), but it seems GH Pages does not add the correct Content-type header even the SVGZ file itself is correct.
I raised a question at GH Community about this since this is not Hugo related anymore.
Thanks for your help @pamubay et al.
You might want to edit the thread title, as this discussion might be valuable for future visitor learning about svgz. 
For some reason I cannot edit the title anymore. There is maybe a limit how many times the title can be changed or a cooldown.
Hello all,
Not a Hugo related thing, but I finally solved my issue with serving SVGZ images on GitHub Pages.
It turned out that the root cause was NOT the missing Content-Type: charset=utf-8 HTTP response header, but double-compression of SVGZ images by GitHub Pages web server.
One needs to use e.g. CloudFlare to 1) trick GitHub Pages web server not to compress SVGZ images by modifying HTTP Request headers and then 2) to add correct HTTP Response headers. I wrote a guide here:
HOWTO serve SVGZ images from GitHub Pages
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.