GitHub Community
Embedding a SVG #21945
-
|
demo of my problem: When I host my SVG on a third party file hoster and link it in the README.md my SVG is displayed normally. You can see the SVG shaking and going through various colors. But when I upload the SVG to github and reference the SVG in the README.md it is black but still shaking. Inspecting the element I see that GitHub adds a to the URL. I tried to set it to false in the README.md but it wouldn’t let me. If you go to the file in GitHub you can see it is colored there. I want to host the file on GitHub so I have more control compared to other file hosters (deleting and more importantly modifying the SVG). |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
|
Hi @nntin Thanks for being part of the GitHub Community Forum! Embedding SVGs in README files is currently disabled, because they can contan JavaScript which creates a security risk. At this time, we don’t have a workaround for this, but I’ll definitely let the team know that you’re interested in one. I can’t promise if or when changes will happen, but your feedback is in the right hands. Though they aren’t direct replacements for an SVG, you might try a GIF or video file instead, in the meantime. Thanks again for being here, @nntin! I hope this helps. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the reply! I’m really hoping there is going to be a change since my project relies entirely on SVGs. :slight_smile: I’m a bit confused. It seems there are some inconsistencies with the security risk. GitHub allows SVGs hosted on third party websites. When comparing my example you can see the two SVGs are identical, one is hosted on GitHub while the other is hosted on mixtape.moe. How come the SVG hosted on a third party website does not get sanitized? Furthermore why does the SVG work as normal when visiting the SVG file directly within the GitHub repo when the same SVG does not work when viewing it from a README file. |
Beta Was this translation helpful? Give feedback.
-
|
@nntin Sorry for any confusion. Let me see if I can explain a little better. We return a content-type of text/plain for SVG images served from raw.githubusercontent.com. We do that to prevent any JS execution. The reason we don’t want to have JS executed with raw.githubusercontent.com is because it might be possible for someone to exploit our site through that mechanism. We generally want to eliminate all security problems no matter how far fetched they are. I hope you understand why I can’t go into the details, and I hope you trust we have a good reason for doing so. In any case I’ve shared your feedback with our team about the problems this creates in situations like yours. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, However, if you put at the end of the raw URL when requesting an SVG, it serves the SVG just fine with the right Content-Type. EDIT: Ah, now I see the sanitize was mentioned before… I only looked at a bit of the discussion. |
Beta Was this translation helpful? Give feedback.
-
|
You might want to look at https://rawgit.com/ as well, I’ve used it in the past for small projects. |
Beta Was this translation helpful? Give feedback.
@nntin Sorry for any confusion. Let me see if I can explain a little better.
We return a content-type of text/plain for SVG images served from raw.githubusercontent.com. We do that to prevent any JS execution. The reason we don’t want to have JS executed with raw.githubusercontent.com is because it might be possible for someone to exploit our site through that mechanism. We generally want to eliminate all security problems no matter how far fetched they are. I hope you understand why I can’t go into the details, and I hope you trust we have a good reason for doing so.
In any case I’ve shared your feedback with our team about the problems this creates in situations like yours.