Jekyll does not set the correct Content-Type for SVG files #406

postmodern opened this Issue Sep 25, 2011 · 23 comments


None yet

postmodern commented Sep 25, 2011

I noticed that Jekyll was serving SVG files with the Content-Type set to application/octet-stream. This prevents browsers from correctly rendering SVG files.


envygeeks commented Sep 25, 2011

Jekyll does not serve content, it merely renders content. If you are using github pages you should file a support ticket and let them know there, if you are using Jekyll on your own server then you should check that your server is serving the correct mime types with mimemagic or static mime types, if you are testing with webrick this is probably an unfortunate side-affect of a super-slim http server.


postmodern commented Sep 25, 2011

Jekytll does serve content, via the --server option. Additionally, jekyll is able to set the correct Content-Type for PNG and JPEG files.


envygeeks commented Sep 25, 2011

Sir, Jekyll does not serve content. This is webrick, please see ... and while it could be fixed in Jekyll, this problem should also be sent upstream.

Unless I'm mistaken, the MIME type store is already being modified to handle JS correctly. Why not just add another line for SVG and call it a day? Submitting upstream in addition seems reasonable as well.


envygeeks commented Sep 25, 2011

There is no problem with fixing it here, I just believe it should also be sent upstream too (so I mentioned it) though I don't know what version of Ruby he is using and if that is even the case anymore with Ruby 1.9+ since I would hope they continue to update their mimes as technologies advance in browsers, either way I've submitted a pull that fixes this issue.

+1 to getting the SVG MIME Type added. I can then remove setting it in jekyll-svg-plugin.


postmodern commented Sep 25, 2011

Ah ha, was not aware that WEBrick was handling the mime-types. The quick fix would be to just define the svg mime-type, a more robust solution would be to use Rack and Rack::Directory.

I can also submit a bug report upstream. Just tested WEBrick::HTTPUtils::DefaultMimeTypes on Ruby 1.9.2-p290 and it still does not have an svg mime-type. Also surprised that WEBrick is also missing the 'js' mime-type.


postmodern commented Sep 25, 2011

Upstream bug report (with patch):


envygeeks commented Sep 26, 2011

Upstream fixed this issue last night in webrick too: they also fixed the JS issue... thanks for uploading that one in that ticket as well >.< I'm going to leave the pull open though since we can't expect everyone to get the changes that fast.

I can't get Jekyll to serve a SVG image. I'm trying to load a sprites SVG file in my CSS. The response header contains a content type of application/octet-stream. I'm using Mac OS X 10.7.3, Jekyll 0.11.2, Ruby 1.9.3-p194 and Webrick 1.3.1. I can see that you've closed this issue and it was closed in Webrick (, so I apologize if I'm doing some stupid. The SVG image works fine using python -m SimpleHTTPServer 8080.

brodo commented May 10, 2012

I've got the same problem LandonSchropp has.

fidanov commented May 22, 2012

I've got it too, and my specs are (exactly) the same as those of LandonSchropp.

rdeits commented Jun 29, 2012

I also have the same problem as LandonSchropp. I can work around it by running jekyll and python -m SimpleHTTPServer simultaneously, but this isn't ideal since the jekyll --server is otherwise so excellent.

I'm also having the same issue. Does anyone know how I can get SVG files to load through jekyll --server? From the comments it looks as if this should be fixed, but it's not the case for me. It makes testing really difficult!

rdeits commented Jul 20, 2012

My current workaround is to run jekyll without the --server flag, then run "python -m SimpleHTTPServer" in a separate terminal from the _site directory. This serves the site from port 8000 by default and allows me to view SVG images.

One weird thing I've noticed is that Chrome seems to cache SVGs in some strange way that I can't entirely figure out--reloading (even Cmd+shift+R) won't reload the SVGs if they've changed. Firefox does not have this problem.

Sounds similar to me. My current workaround is to run apache to serve up the files (I'm on OSX so it's built in). Although it'd be nicer to run it through jekyll --server to keep it lightweight. And it'll also save me setting up a new virtual host for each site.


envygeeks commented Jul 21, 2012

Please stop spamming the ticket with "I have the same issue, the same issue affects me" we all get these emails and it's almost annoying to hear about Python being used to power Ruby (even though I love both Python and Ruby) when you could have just edited (and by edit I mean copy the line to a new line and edit it) until the Ruby fix is released. Also @markstar I don't understand why you would "need" a new virtual host for every client when you could convince all your projects to start with the same ip and port...

for anyone mystified by this... since there arent any clearcut solution posted... thanks to @envygeeks chastisement.. i saw from what he said, there IS a way to fix this, easily... you need to add the following line 'svg', 'image/svg+xml'
right below 'js', 'application/javascript''
to your actual jekyll "bin" file. (be sure to maintain the space below that line, as it is needed. in my case, this file was located at /Library/Ruby/Gems/1.8/gems/jekyll-0.11.2/bin/jekyll but use locate jekyll to find it on yours... svg's work aok now! cheers. such an easy fix... why hasnt it been pulled?

@mralexgray I can't thank you enough for this. I'm just getting started with Jekyll and after fighting to get preprocessors rolling I nearly threw in the towel when SVG files weren't working.

Is there a way to change Jekyll/Webrick via a plugin? That is, can I make this change without patching Jekyll/Webrick itself? Thanks!

Answered my own question.

Just add this in the _plugins dir:

require 'webrick'
include WEBrick 'svg', 'image/svg+xml'

parkr closed this in 4f7881b Jan 25, 2013

jekyllbot locked and limited conversation to collaborators Feb 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.