Are HTML files safe to open, and what the warning means

Chrome, Outlook and Windows warn before opening a downloaded .html because any HTML file can show a form, run a script and send what you type somewhere.

Are HTML files safe to open? Usually yes, and the warning you see is not a verdict on the particular file you were sent.

The warning when opening a downloaded HTML file. It is about what any HTML file could do, not yours.
The warning when opening a downloaded HTML file. It is about what any HTML file could do, not yours.

Chrome, Outlook and Windows warn before opening a downloaded .html because any HTML file can show a form, run a script and send what you type somewhere, and nothing in the file tells them yours will not.

The safe way to look at one is a sandboxed viewer. The way to stop your own readers seeing the warning is to send a link instead of a file.

This guide covers what each warning is reacting to, the four-step check, and why local files are treated as less trustworthy than web pages.

Are HTML files safe to open: what the warning is reacting to

An HTML file is not a document that gets displayed. It is a set of instructions the browser carries out, and it can include a script and a form. Downloaded from a source your machine cannot vouch for, that is code from a stranger about to run locally.

The specific worry is well established: a page that imitates a sign-in screen, collects what you type, and sends it elsewhere.

Running from a local file it is particularly effective, because there is no suspicious web address to notice and nothing for a link filter to block.

Security teams call the delivery method HTML smuggling, and it is common enough that whole organisations block .html attachments outright.

Your report is not that. But nothing in the file distinguishes it from that, which is the whole difficulty.

The warnings you are likely to meet

Where What it says What triggered it
Chrome download shelf "may be dangerous" or "blocked" The download came over plain http, or Safe Browsing could not verify it
Outlook, before opening an attachment "You should only open attachments from a trustworthy source" Outlook prompts for any attachment type that can carry scripts
Windows, on opening a downloaded file "Open File - Security Warning" The file carries a mark saying it came from the internet
Gmail attachment preview The source code, not the page Gmail no longer renders HTML attachments in the preview
A company mail gateway Nothing; the attachment is gone The gateway strips .html by policy

Different wording, one reason. Chrome, Outlook and Windows are each reacting to the file type and where it came from, not to what is inside.

Why local is treated as less trustworthy, not more

Counter-intuitive but important. Web pages are kept apart from one another by origin rules: a page from one site cannot read another site's data.

A file opened from your disk does not have a normal origin, so those rules do not apply in the usual way. Browsers respond by restricting local pages in their own ways and by warning before opening them.

This is also why some features of your page may silently not work when opened from a disk and work fine once served from an address.

How to check a file you were sent: 4 steps

  1. Do not open it from Downloads yet. A double-click runs the file with the fewest restrictions your system allows.
  2. Read it as text first. Open it in any text editor. You are looking for three things: a form asking for a password, a script posting to an address you do not recognise, and imagery imitating a service you use. A report has none of those.
  3. Render it somewhere contained. Drop it into the HTML file opener. It draws the page in a walled-off frame with no access to your accounts, storage or the surrounding site, so a malicious page has nothing to steal and a good page looks exactly as intended.
  4. If it turns out to be your own page, send an address next time. The whole class of warning belongs to file delivery, and disappears with it.
The safe way to look at a file you were sent: a sandboxed viewer that cannot reach your machine.
The safe way to look at a file you were sent: a sandboxed viewer that cannot reach your machine.
The page you are reading Sandboxed frame the pasted HTML runs here it cannot reach anything outside this box
A sandboxed frame can draw the page and run its scripts without reaching anything outside itself.

What the sandbox actually is

The frame restriction is a single attribute:

<iframe sandbox="allow-scripts" srcdoc="..."></iframe>

allow-scripts lets the page run. What is not granted matters more: without allow-same-origin the frame is treated as a separate origin, so it cannot read the parent page's cookies or storage, and without allow-top-navigation it cannot send you somewhere else.

Granting scripts and same-origin together undoes the protection entirely. See the sandbox attribute for the full list of permissions and what each one gives away.

Avoiding the warning for your own readers

There is no way to sign or mark an HTML attachment as trustworthy. The warning belongs to the delivery method.

Your own readers never see the warning if you send an address instead of a file.
Your own readers never see the warning if you send an address instead of a file.

Send an address instead. Fetching a page over https is ordinary browsing: no warning, no download, no decision for the recipient to make. It also removes the attachment filtering problem and the phone problem at the same time, because all three have the same root: you were handing over a file where a page was wanted.

Sending the file itself ✗ Often filtered by mail security rules ✗ May open as plain text on a phone ✗ Every fix means a new attachment ✗ No way to know who opened it ✗ Recipient needs the right app Sending a link ✓ Passes through mail and chat ✓ Renders in the phone browser ✓ Fix once, link stays the same ✓ The address is the single source ✓ Any browser is enough
A file the recipient has to decide about, versus a page they simply read.

Publishing the page is the fix. In NOS the pasted HTML is served as a page from a normal web address, so there is nothing for the recipient to download, decide about, or be warned about, and the address stays the same when you revise.

Can the warning be turned off?

Technically, parts of it. Chrome's download protection can be lowered in its safety settings, Outlook's attachment prompt can be silenced per file type in the registry, and the Windows mark can be cleared from a file's properties. All three are the wrong fix.

They remove the warning for every file, including the one that deserves it, and none of them does anything for the person you send files to, who has their own settings. Treat the warning as information about the delivery method, and change the delivery method.

If you must send the file anyway

Sometimes the recipient's rules require a file, or they will read it offline. Three things reduce the friction. Zip it, so the mail system sees an archive rather than an HTML attachment; some gateways look inside, but many pass it.

Tell the recipient in the message what the file is and that their system will warn. And make the file self-contained, so that when they do open it, it renders rather than arriving as unstyled text and making the warning look justified.

The short version

Local HTML file Page at an address
Warning on open Often No
Runs outside normal origin rules Yes No
Some features withheld Yes No
Recipient has to make a judgement call Yes No
Opens on a phone Rarely Always

Questions people ask

Why does my browser warn about an HTML file but not a PDF?

A PDF is displayed by a viewer; an HTML file is executed by the browser. It can contain a form and a script, and opened from disk it runs outside the origin rules that keep web pages apart. That combination is the standard shape of a phishing page, so the file type gets the warning.

Which warnings am I likely to see?

Chrome may mark a download as possibly dangerous, particularly when it came over plain http or Safe Browsing could not check it. Outlook asks before opening any attachment that could contain scripts. Windows shows an Open File security prompt for files that came from the internet. The wording differs; the reason is the same.

Is a local HTML file more dangerous than a web page?

In one respect, yes. A web page is confined by its origin; a file opened from disk does not have a normal origin, so browsers restrict it in their own ways and warn before opening it. A page served at an https address is ordinary browsing.

How can I check a file before opening it?

Read it as text in an editor, looking for a password form or a script that posts to an address you do not know. Then render it in a sandboxed viewer, which draws the page inside a frame that cannot reach your accounts or your machine.

How do I stop my own recipients getting the warning?

Do not send the file. Publish the page and send its address. Fetching a page over https produces no warning, no download and no decision for the recipient.

Keep reading

HTML file openerFree HTML file opener: drop an .html file and see the page it was meant to draw. Why double-The iframe sandbox attribute: every permission explainedThe iframe sandbox attribute starts from nothing allowed and grants back what you list. WhatThe file:// protocol: what works differently when a page is opened from diskfile:// is the address for a page opened from disk. It is not on the web: only this machine HTML to linkTurn HTML into a link in 5 steps: check the page, paste it into a NOS document, copy the shaHTML button not clickableA dead button is usually covered by an invisible element, disabled, or missing its handler. HTML canvas blurryA canvas looks soft because its buffer is smaller than its box on screen. Set the width and