What does “Not allowed to load local resource” mean?

A page served over http or https tried to load a file:/// URL — an image, stylesheet, iframe or link pointing at a disk or network share. Chrome and Edge never let a web page reach the visitor's filesystem, so the request is refused and logged in the console with that message.

Why does it work when I open the HTML file directly?

Opened from disk, the page itself is file://, and a file:// page may display other local files. Once the same page is served from a server, a preview tool, a CMS or an iframe, it is an http page and every file:/// reference in it is blocked.

How do I fix an that only works on my computer?

Copy the image next to the page and reference it relatively (images/chart.png), or embed it as a Base64 data URI so it lives inside the HTML. An absolute path to your own disk can never work for anyone else, whether or not Chrome blocks it.

Can I link to a file on a network share from an intranet page?

Not from Chrome or Edge by default. A file://server/share link on an http page is blocked like any other local resource. Internet Explorer allowed it, which is why old intranets break after migration. Serve the files over HTTP from the share, or move them to a document system with web links.

Is there a Chrome setting or extension to allow it?

Only workarounds: launching Chrome with security flags, or extensions that intercept file links. Both work on one configured machine and nowhere else, and both lower a protection that stops any website from reading your disk. Fix the reference instead.

“Not allowed to load local resource”

The page loads, but an image is a broken icon, a link does nothing, or an iframe is blank. The console says:

Not allowed to load local resource: file:///C:/Users/you/project/img/chart.png

The URL after the colon is the whole diagnosis. Something in the page points at a file on a disk, and the page itself is not on that disk.

Why Chrome blocks it

A page served over http:// or https:// is a web page, and web pages don't get to touch the visitor's filesystem. If they could, any site you visit could embed file:///C:/Users/you/Documents/ and read it. So Chrome and Edge refuse every file:/// subresource and navigation from a web origin, with no prompt and no per-site exception.

The same file opened by double-click is fine, because then the page is file:// too. That is the trap: it works on the machine that made it, and breaks the moment it is served, previewed or embedded anywhere else.

Where the `file:///` came from

Source of the page	Usual culprit
Exported from Word, Excel or an old editor	Absolute `C:\…` paths written into `src` and `href`
Generated by a script or notebook	`os.path.abspath()` / `Path.resolve()` in the template
Coding agent wrote it	It used the absolute path of its working directory
Intranet or SharePoint page	Links to `file://server/share/…` from the IE era
Electron/desktop app preview loading a remote page	Mixing `file:` assets into an `http` document
Test report viewed from a CI artifact server	Screenshots referenced by absolute runner paths

Open DevTools → Console to see every refused URL, or Elements and search for file: to find them in the markup.

Fix 1: make paths relative

Copy the files next to the page and point at them relative to it:

<!-- breaks everywhere except your machine -->
<img src="file:///C:/Users/you/project/img/chart.png" />

<!-- works anywhere the folder goes -->
<img src="img/chart.png" />

In generators, compute the path relative to the output file — os.path.relpath(image, start=out_dir) in Python, path.relative(outDir, image) in Node — rather than writing an absolute one. Watch out for backslashes too: img\chart.png is a Windows path, not a URL, and breaks on every server.

Fix 2: put the files inside the HTML

For a page you're going to send or upload rather than host as a folder, embed the resources so there is nothing left to load:

One image → a Base64 data URI with the image to Base64 converter.
A whole page with images, CSS and fonts → the HTML inliner rewrites every reference in one pass and lists the ones it couldn't find.

The result is one self-contained HTML file that renders the same from disk, a server, an email or an iframe.

Fix 3: links to files on a share

A file://fileserver/finance/q3.xlsx link on an intranet page was how departments shared documents in the Internet Explorer years. In Chrome and Edge it is a dead link. The options are to serve that share over HTTP, move the documents into a system with web URLs, or — for HTML reports specifically — publish them and link to the published page.

Don't fix it with flags

Search results suggest launching Chrome with --allow-file-access-from-files or --disable-web-security, or installing an extension that opens local links. Each works on exactly one configured machine, and the second one switches off the same-origin policy for every site you visit in that session. Your recipients won't have done it, so the page is still broken for them.

Related errors

from origin 'null' has been blocked by CORS policy — the page is on disk and is trying to fetch a sibling file: CORS error from origin 'null'.
Broken images only after sending the file — the images were never sent: images not showing.
Mixed Content: … requested an insecure resource — http:// on an https:// page: mixed content.

Try it

Comma is free — publish the HTML with its images, send one link, and let people comment on the exact chart instead of a screenshot of it.

Publish a report →