Why does htmlpreview.github.io break my page?

It fetches the raw file and rewrites it in the browser, so anything the page loads afterwards is subject to cross-origin rules and to relative paths that no longer resolve the way they did on disk. Stylesheets and scripts committed alongside the file usually survive; fonts, XHR/fetch calls to sibling data files, iframes and service workers usually do not.

Does htmlpreview.github.io work with private repositories?

No. It reads through raw.githubusercontent.com, which needs the file to be publicly readable. If the repo is private the preview is a blank page or a 404, and there is no token you can hand it.

What is the most reliable way to view an HTML file from a repo?

Publish the built artifact instead of proxying the source. A self-contained HTML file, or a zip of the folder, uploaded to a destination that serves it from a real origin — that removes the cross-origin rewriting entirely, and lets you keep it private.

Is raw.githack.com better?

It is more reliable for assets, because it serves files with the correct Content-Type from its own origin rather than rewriting them in the page. It still needs the repository to be public. See the raw.githack comparison.

htmlpreview.github.io alternatives

Everyone finds it the same way. You have an HTML file in a repo, GitHub shows you the source instead of the page, you search for a workaround, and you land on prefixing the blob URL with htmlpreview.github.io/?.

It works, right up until it doesn't — and it fails in a way that wastes an afternoon, because the page almost renders.

Why it breaks

htmlpreview is a client-side proxy: it fetches your file from raw.githubusercontent.com and injects it into a page on its own domain. Everything downstream of that inherits the consequences.

Relative paths move. ./data/results.json was next to your file on disk. In the preview it is resolved against a different origin, and the fetch 404s.
Cross-origin rules apply. Fonts, XHR, fetch(), workers and some iframes are subject to CORS against raw.githubusercontent.com — which does not serve the headers your page assumed.
Public repos only. It reads the raw endpoint anonymously. A private repo renders nothing.
Nothing is shareable in a durable way. The URL is a proxy of a branch. Push to main and the "shared" link silently shows different content; delete the branch and it shows nothing.
No review layer. The person you sent it to can only reply in chat.

The shortlist

1. Publish the artifact, not the source — Comma

The structural fix is to stop proxying a file out of version control and start serving the built thing from a real origin. Drag the file into /new, or publish it from the same CI job that produced it:

- name: Publish report
  run: |
    curl -X POST https://commareports.com/api/v1/reports \
      -H "Authorization: Bearer ${{ secrets.COMMA_API_TOKEN }}" \
      -H "Content-Type: application/json" \
      -d "$(jq -n --arg h "$(cat dist/report.html)" \
            '{title:"Build report", html:$h, visibility:"team"}')"

Because the report is served from one origin, relative assets in a zip bundle resolve the way they did locally, and the cross-origin failures disappear. On top of that: private / team / domain / link visibility, so private repos are no longer a dead end, and anchored comments so the feedback lands on the paragraph instead of in a DM.

Not for: browsing a repository. This replaces the share step, not GitHub.

Pricing: Free — unlimited reports, viewers, commenters and revisions.

Publishing from CI →

2. raw.githack.com — the better proxy, same public-repo limit

Serves the file from its own CDN with the correct Content-Type instead of rewriting it in the browser, which fixes most asset problems. Still public repos only, still pinned to a ref you have to remember to bump. See raw.githack alternatives.

3. GitHub Pages — the supported answer for a repo's own site

If the HTML is part of the project rather than an output of one run, Pages is what it is for: a real origin, real relative paths, git as history. Public unless you are on Enterprise, and deployed from a branch or action rather than from a file. See GitHub Pages alternatives.

4. `python -m http.server` — the two-second local answer

If you only need to look at it yourself, serve the folder locally and open localhost. That removes every path and CORS problem instantly, and shares with exactly nobody. See serving an HTML file locally.

At a glance

Option	Assets survive	Private repos	Stable link	Comments
Comma	Yes (bundle)	Yes	Yes	Yes
htmlpreview	Often not	No	No (branch)	No
raw.githack	Mostly	No	Ref-pinned	No
GitHub Pages	Yes	Enterprise	Yes	No
Local server	Yes	n/a	n/a	No

Checked September 2026.

How to choose

Just want to see it once? Serve the folder locally.
Public demo out of a public repo? raw.githack, or Pages if it is permanent.
Sending it to someone who will have opinions — or the repo is private? Publish the file and keep the thread on it.