FAQ
Who runs this thing?
Hi, I'm Pavel Puchkin.
Why is this necessary? Can't I just load files from my favorite service directly?
When you request a file from source control hosting services, they are usually served (in the case of JavaScript, HTML, CSS, and some other file types) with a Content-Type of text/plain. As a result, most modern browsers won't actually interpret it as JavaScript, HTML, or CSS.
They do this because serving raw files from a git repo is relatively inefficient, so they want to discourage people from using their repos for static file hosting.
rawgit.hack acts as a caching proxy, forwarding requests to the corresponding service, caching the responses either for a short time (in the case of development URLs) or permanently (in the case of CDN URLs), and relaying them to your browser with the correct Content-Type headers.
The caching layer ensures that minimal load is placed on each service, and you get quick and easy static file hosting right from a repo. Everyone's happy!
How does rawgit.hack handle HTML files?
rawgit.hack serves HTML pages exactly as their authors wrote them, without any review or modification. This means anyone can host an HTML page in a public Git repository and share a rawgit.hack link to it. Malicious actors have exploited this to serve phishing pages — sites that impersonate banks, login forms, or other trusted services — through rawgit.hack, which leads to the service getting blocked by browsers, antivirus software, and corporate firewalls.
To prevent this, rawgit.hack adds a brief confirmation step before opening HTML pages. The notice page shows you the full address you're about to visit and asks you to confirm you want to proceed. This makes it harder to use rawgit.hack as a silent redirect to a malicious page, since the destination URL is always shown to the visitor first.
Once you confirm, the page opens normally, and you won't see the notice again for any page in the same repository for the next 24 hours. Non-HTML files (scripts, stylesheets, images, etc.) are not affected.
The notice is only shown to actual browsers — HTTP libraries and command-line tools (curl, wget, Python requests, etc.) are not affected and will receive the file directly. If you use browser automation tools that emulate a real browser (Playwright, Puppeteer, Cypress), set the cookie __Http-phish=1 on the domain you're requesting before navigating to the page, and the confirmation step will be skipped.
What source code services are supported?
Currently, the following services are supported:
Is rawgit.hack associated with any of the supported hosting services?
No, rawgit.hack is not associated with them in any way. Please don't contact their support asking for help with rawgit.hack. They'll give you a weird look and back away slowly.
What's the difference between development and CDN URLs?
When you make a request to a development URL, the server loads the requested file from the corresponding service, serves it to your browser with the correct Content-Type header, and caches it for a short time. If you push new changes to your repo, you can reload and see them within a few minutes, which makes development URLs useful for low-traffic testing or sharing demos during development.
Requests to CDN are routed through CloudFlare's content delivery network, and are cached for a year the first time they're loaded. This results in the best performance and reduces load on rawgit.hack and the underlying service, but it means that reloading won't fetch new changes.
During development, when traffic is low and freshness is more important than performance, use development URLs. For anything you share with the public or push to production, use CDN URLs.
Can I use a development URL on a production website?
Please don't. Use CDN URLs for anything that might result in heavy traffic. Development URLs are for low-traffic testing and sharing temporary examples or demos during development.
If you do, and the service gets a lot of requests from the same domain, all further requests will be temporarily redirected to the corresponding CDN URLs — meaning clients won't see changes you push to your repo on the next request.
How long does the CDN cache files? How can I make it refresh my file?
The CDN caches files for one year based on their path. It ignores query strings. This is done both to improve performance and to make it possible for the CDN to handle massive amounts of traffic without causing excessive load on the underlying services.
To ensure that the CDN always serves the version of the file you want, use a git tag or commit ref in the file's path instead of a branch name, and update the URL if you push a new version of the file.
So, instead of a URL like /user/repo/BRANCH/file, use a URL like /user/repo/TAG/file or /user/repo/COMMIT/file.
I need guaranteed 100% uptime. Should I use rawgit.hack?
Probably not.
rawgit.hack is a free service and cannot provide any uptime or support guarantees, even for CDN URLs. While I do my best to keep things running, sometimes there are network or provider issues outside my control, sometimes abusive traffic temporarily affects response times, and sometimes I break things (although I try really hard not to).
You can take a look at the uptime stats to decide if this service is stable enough for you. On the other hand, the service has been working since 2013, for more than a decade, without major outages. Doesn't this mean something?
How can I contact you?
For critical issues — service outages, abuse, spam, or general feedback — send me an email. For non-critical bugs, please file an issue on GitHub.
Can I somehow purge cached URLs?
Yes — use the cache purge form. Available to Patreon sponsors.