If you import an HTML file and the images and relative links are broken afterward, the cause is usually not the import itself. An HTML file stores text that points to other files, and a relative path such as images/hero.png only works when the browser knows which base URL to start from. Once the markup is shown in a different document, that starting point changes, so the same path can point to a location that has no such file.
This article takes a .html file, shows what happens to its src and href values after Import File in the WYSIWYG HTML Editor, and ends with a checklist for repairing each reference. I also explain what the HTML Code Editor preview can confirm and what it cannot. Neither editor is documented as bringing along or restoring the files your markup references.
Table of Contents
Why Images and Relative Links Break After You Import an HTML File
Importing a file and importing its dependencies are two different things. The visual editor on the homepage can import an HTML or TXT file, and the HTML Code Editor offers a live preview, but nothing in either description says that neighboring images or linked documents come along. Treat the import as markup only.
A tag such as <img src="images/hero.png"> does not contain a picture. It contains a reference, and the browser fetches the resource when the page renders. A reference without a scheme and host is a relative reference, and the browser resolves it against a base URL. In the HTML Living Standard, the document base URL comes from the first applicable <base> element that has an href, and otherwise falls back to the document’s own address. It is not a permanent property of the markup, so it does not stay attached to the folder the file came from. The MDN guide to resolving relative references describes the same resolution rules.
Two more facts make local files confusing. Choosing one file in a browser gives a page access to that selected file, not to the folder around it, as the MDN notes on using files from web applications explain. And a path that worked on your disk, because an images folder sat next to the HTML file, means nothing to a website that never received that folder. Three things can therefore go wrong together: the base changed, the referenced files are not at the new destination, and the head that might have declared a base or linked stylesheets is gone.
A Worked Example: Relative Paths Versus Absolute URLs
Suppose the original page lived at https://example.com/articles/page.html and contained the markup below. The domain is fictitious, and none of this claims that those files exist.
<img src="images/hero.png" alt="Mountain trail at sunrise"> <img src="/images/logo.png" alt="Site logo"> <img src="https://example.com/articles/images/hero.png" alt="Mountain trail at sunrise"> <a href="contact.html">Contact</a>
Now compare where each reference points against the original page and against a different document at https://editor.example.net/app/.
| Reference | Against the original page | Against the new document |
|---|---|---|
images/hero.png | https://example.com/articles/images/hero.png | https://editor.example.net/app/images/hero.png |
/images/logo.png | https://example.com/images/logo.png | https://editor.example.net/images/logo.png |
https://example.com/articles/images/hero.png | unchanged | unchanged |
contact.html | https://example.com/articles/contact.html | https://editor.example.net/app/contact.html |
There are three kinds of reference here. A folder-relative path like images/hero.png starts at the folder of the base URL. A root-relative path like /images/logo.png starts at the root of the base URL’s site, not at the HTML file’s folder, so it still depends on the base. An absolute URL carries its own scheme and host, so it does not change merely because the markup is displayed somewhere else.
You can calculate these destinations yourself with the URL constructor. The JavaScript Editor runs code in the browser and shows synchronous console output, so this short script works there. Only run code you wrote or trust.
const originalPage = "https://example.com/articles/page.html";
const newBase = "https://editor.example.net/app/";
const refs = ["images/hero.png", "/images/logo.png", "contact.html"];
for (const ref of refs) {
console.log(new URL(ref, originalPage).href);
console.log(new URL(ref, newBase).href);
}The output should match the table. Keep in mind that this only computes addresses. It does not fetch anything, so it cannot tell you whether a file exists at the result.
What Import File Changes: a New Context and a Missing Head
In the WYSIWYG HTML Editor, Import File reads an HTML or TXT file into a Quill-based rich-text editor. That editor works with body-level content, and the original document’s head is not kept. The head matters here because it is where a document can declare a <base> element, link external stylesheets, and set metadata. The HTML Standard defines these elements as head metadata, and the MDN page for the base element shows how it sets the URL that relative references use.
If the original file relied on a base element, that instruction disappears with the head, and the relative paths fall back to whatever document now displays them. If the original linked its CSS from the head, those stylesheets disappear too. That is a separate problem from broken images, so a page can lose its layout even when every image loads. The same missing-head behavior appears on the export side, which is covered in the article on why the downloaded HTML is missing the doctype, head and body.
It is tempting to paste a <base> element into the body content and call it fixed. I would not rely on that. HTML specifies it as head metadata, and its effect depends on the document that is actually used for rendering. Content inside the visual editor is not a full document of its own. Quill also removes markup it does not support, so an element that survives in one view may not survive the round trip.
TXT files are different, because plain text has no references to resolve. They have their own import quirk, though: TXT import collapses line breaks, which is explained in a separate guide. For HTML files, assume that every src and href survives as a string and that nothing guarantees it still points anywhere useful.
What the HTML Code Editor Preview Can and Cannot Show
The HTML Code Editor gives you syntax highlighting, auto-closing tags, a sandboxed live preview, and beautify and minify buttons. It has no validation. The preview is useful for a quick look at whether references render at all: a broken-image icon or the alt text appearing in place of a picture tells you that the address did not load in that context.
Its limits matter just as much. The preview has its own rendering context, so I would not assume it keeps the base URL of the file you imported, loads sibling files from your computer, or reproduces the original page. A relative path that fails in the preview does not prove the path is wrong for your final site, and a relative path that happens to load does not prove it will load once the page is published somewhere else.
One practical use is readability. Long, minified markup hides its references, so run it through the HTML Beautifier or the editor’s beautify button and read each src and href literally. Beautifying improves layout only. It does not repair a bad path, restore a removed head, or check that a target exists.
Use the preview as a rendering check for markup, nothing more. For links, an unresolved target looks perfectly normal in rendered text, because an anchor with a wrong href still looks like a link. You only find out when you open its destination.
Repair Checklist When Imported HTML Images and Relative Links Break
Work through the references in order rather than guessing at fixes.
- Inspect the literal
srcandhrefvalues in the imported markup. Note which are folder-relative, root-relative, or absolute. - Find the original page URL and any original
<base>element. Without those you cannot know where the author intended each path to start. - Calculate the intended destination of each reference, by hand or with the URL constructor script above.
- Open each destination and confirm the image or document is actually there. A well-formed address says nothing about whether a file exists.
- Replace broken references with verified, publicly reachable HTTPS URLs, or rewrite the paths for the location where the page will eventually be published and deploy the referenced files to match.
- Re-check the result in the HTML Code Editor preview, then again on the published page.
Absolute URLs avoid this particular base-change problem, but they are not magic. They still fail when the resource is removed, moved, or inaccessible to the visitor, so verify them like any other reference. Also remember that a root-relative path only works if the new site really has that file at its own root.
The same idea affects other workflows. If you wonder why relative Markdown links lost their destinations after you copied rich text into Word, the reason is again that a relative link has no base once it leaves its original context.
Check the Result Before You Publish
Keep the checks separate. A clean preview is a rendering check. It is not syntax validation, it is not proof that every link target exists, and it says nothing about how the page behaves at its final address. After you replace references, load the page where it will actually live, open every changed link, and confirm each image displays. Keep your original HTML file as a source of truth, because imported content may have been normalized by the editor and cannot be perfectly reconstructed afterward.
Frequently asked questions
Does Import File upload the images my HTML file references?
Nothing in the editor’s description says it does. Import File reads an HTML or TXT file as markup, and the image tags keep whatever path they had. Treat each src as a reference you must make resolvable yourself, either with a public HTTPS URL or with files deployed at the right location.
Why did the same image work in the original page but not after import?
The original page resolved images/hero.png against its own address, or against a base element in its head. After import, the markup is shown in a different document with a different base, and the visual editor does not keep the original head. The path stays the same string but points somewhere else.
Is an absolute URL always a safe fix?
It solves the changed-base problem, because an absolute URL does not depend on where the markup is displayed. It does not guarantee the file still exists or is reachable. Open each absolute URL and confirm the image or page loads before you rely on it.
Can I add a base element to fix the paths?
A base element is head metadata, and its effect depends on the document actually used for rendering. Pasting it into body content in the visual editor is not a dependable fix. Rewriting the individual src and href values is more predictable, because each reference then stands on its own.
Why does /images/logo.png fail even though I copied the images folder?
A root-relative path starts at the root of the base URL’s site, not at the folder containing the HTML file. The file would have to exist at the root of the site that displays the page. Copying a folder next to the HTML file does not satisfy that.
Will the HTML Code Editor preview load files next to my local HTML file?
Do not assume so. Choosing a file in a browser exposes that selected file to the page, not an unrestricted view of its directory. The preview has its own rendering context, so use it to inspect markup and see whether references render, not to prove that local sibling files will load.
Does a working image in the preview prove the published page will work?
No. The preview shows that the address loaded in that context. Your published page has a different address and possibly a different base, so a relative path can behave differently there. Test the final page and open every changed link after you deploy the files.
Next steps
When imported HTML file images and relative links are broken, the problem is rarely the markup itself. It is a base URL that changed, files that were never moved, and a head that did not make the trip. Once you can tell folder-relative, root-relative, and absolute references apart, you can calculate where each one should point and check that the file is really there. Your next step: open the original file, list every src and href, work out the intended destinations, and replace each with a verified HTTPS URL or a path that matches where you will deploy the files.
Related tools and resources on HTML Editor Online:
- WYSIWYG HTML Download Missing Doctype, Head and Body: Why It Happens
- WYSIWYG HTML Editor
- HTML Code Editor
- JavaScript Editor
Sources and further reading
- HTML Standard
- HTML attribute value – HTML | MDN
- Using files from web applications – Web APIs | MDN
- Resolving relative references to a URL – Web APIs | MDN
- HTML document base URL element – HTML | MDN
- URL: URL() constructor – Web APIs | MDN
- Advanced WYSIWYG HTML Editor – Create and Edit HTML Easily | HTML Editor Online
- HTML Standard
