` in a monospace
font. The file is fine — something between the file and your eyes is
treating it as text. There are five usual suspects, and they take about a
minute to rule out.
## Tell them apart
| What you see | Likely cause |
| ------------------------------------------------------------ | --------------------------- |
| Address bar ends in `.txt`, or the icon is a text file | Wrong extension |
| Served from a URL; DevTools shows `Content-Type: text/plain` | Server sends the wrong type |
| You're in GitHub, a Drive preview, an email or an IDE | A source-only viewer |
| Text reads `<div>` or `
` with no styling at all | Escaped markup |
| Tags inside a grey box, or after a stray line of text | It's wrapped in something |
## 1. The file isn't really HTML
Files saved from chats, emails and "Save as" dialogs often end up as
`report.html.txt`, and both Windows and macOS hide the last extension by
default. Browsers pick a renderer by extension for local files, so the
page opens as plain text.
**Fix:** show extensions (File Explorer → View → _File name extensions_;
Finder → Get Info), rename to `.html`, reopen.
## 2. The server says it's text
Over HTTP the extension doesn't matter — the `Content-Type` header does.
DevTools → Network → reload → click the document → _Response Headers_. If
it says `text/plain`, the browser is doing exactly what it was told.
`application/octet-stream` usually downloads instead of displaying — that
variant is covered in
[S3 downloads instead of rendering](/fix/s3-html-downloads-instead-of-opening).
A few hosts do this deliberately. Raw file endpoints on code hosts serve
`.html` as `text/plain` so user uploads can't run scripts on their domain,
which is why a raw link to a report never renders —
[htmlpreview alternatives](/alternatives/htmlpreview-github-io-alternatives)
explains the workaround people reach for and why it breaks.
**Fix:** set the object's content type to `text/html; charset=utf-8` on a
host you control, or publish somewhere that serves it correctly.
## 3. You're in a viewer that only shows source
GitHub's file view, Google Drive's preview, most email clients, Slack's
snippet view, and every code editor show HTML as code on purpose —
rendering uploaded HTML would execute someone else's scripts inside their
product. See [Slack won't preview HTML](/fix/slack-wont-preview-html-file)
and [share an HTML file from Google Drive](/share-html-file-google-drive).
**Fix:** open it in an actual browser tab, or paste it into the free
[HTML viewer](/tools/html-viewer), which renders it in a sandbox.
## 4. The markup is escaped
If the page shows `<table>`, or shows `
` as visible text
with no layout at all, the markup was HTML-escaped once too often —
usually by a template, a CMS field or a JSON serializer that didn't know
it was holding HTML.
**Fix:** unescape it once. The [HTML escape / unescape tool](/tools/html-escape)
does this in the browser; then check the result renders.
## 5. It's wrapped in something
Two common versions:
- **A Markdown code fence.** Output copied from a chat often keeps the
` ```html ` fence. Anything rendering that as Markdown shows a
code block. Delete the fence lines.
- **Text before ``.** A log line or a BOM-mangled header
ahead of the document can push some viewers into treating the whole
thing as text. Make `` the first thing in the file.
## So nobody else hits this
Every one of these is a problem the _reader_ has to solve on their own
copy. Publishing the report to a link that is served as `text/html`,
over HTTPS, with its assets alongside, removes all five at once — and
readers can [comment on the page](/comment-on-html) instead of messaging
you that "it's just showing code".
**[Publish an HTML file to a link →](https://commareports.com/)**
### Related
- [HTML report troubleshooting](/fix)
- [My HTML report lost its CSS](/html-report-broken-css)
- [Outlook blocked the HTML attachment](/fix/outlook-blocked-html-attachment)
- [Free HTML viewer](/tools/html-viewer)