# “Not allowed to load local resource” in Chrome — What It Means and How to Fix It

Canonical: https://commareports.com/fix/not-allowed-to-load-local-resource
Published: 2026-10-07

> Chrome refuses a file:/// image, link or iframe on a web page with “Not allowed to load local resource”. Why an http page can never reach your disk, where the C:\ path came from, and how to fix it for good.

# “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:

```html
<!-- 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](/tools/image-to-base64).
- A whole page with images, CSS and fonts → the
  [HTML inliner](/tools/html-inliner) rewrites every reference in one pass
  and lists the ones it couldn't find.

The result is one [self-contained HTML file](/glossary/self-contained-html)
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'](/fix/cors-error-file-origin-null).
- Broken images only after sending the file — the images were never sent:
  [images not showing](/fix/html-images-not-showing).
- `Mixed Content: … requested an insecure resource` — `http://` on an
  `https://` page: [mixed content](/fix/mixed-content-blocked-html-report).

## 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 →](https://commareports.com/)**

### Related

- [Images not showing in a sent HTML file](/fix/html-images-not-showing)
- [The localhost link doesn't work for others](/fix/localhost-link-doesnt-work-for-others)
- [SharePoint won't preview HTML](/sharepoint-html-preview)
- [Same-origin policy, explained](/glossary/same-origin-policy)
- [Free HTML inliner](/tools/html-inliner)