Keep the Base64 data URL when the image has to travel inside one small, portable piece of HTML. Choose to replace base64 image src with hosted image URL in HTML export when a shorter fragment and an image you manage separately matter more. Both choices are valid, and neither guarantees that your CMS will keep or display the image.
The input here is an exported fragment from the WYSIWYG HTML Editor that contains an <img> element whose src starts with data:image/. The expected output is the same fragment with an HTTPS address in src. You can make that edit and preview it in the site’s HTML Code Editor before the fragment goes into the CMS. This guide reflects the sources I checked on November 8, 2026, and the examples are illustrative, not captured tool output.
Table of Contents
Replace Base64 Image src With Hosted Image URL in HTML Export: Quick Answer
Use this rule of thumb. A data URL puts the encoded image bytes inside the HTML, so the fragment stays self-contained for that image. A hosted URL puts only an address in the HTML, so the fragment is shorter, but the browser must obtain the image separately and the host has to stay reachable.
- Keep the data URL when the fragment must move as one piece, the image is small, and the destination CMS accepts
data:images. - Replace it with a hosted HTTPS URL when the markup has become hard to read, when you want to manage or swap the image separately, or when the CMS strips or blocks data URLs.
- Verify either way, because a CMS rule or a content security policy can override what the markup says.
I am not promising a speed improvement from either choice. Loading speed depends on the actual image, its compression, caching and the page around it. A smaller HTML fragment is not proof of a smaller total download.
Data URL Versus Hosted URL: What Changes in the src Attribute
The src attribute of an img element holds a URL. With a data URL, the image itself is encoded into that value. With an HTTPS URL, the value only identifies a resource the browser requests separately. MDN documents both the data: URL scheme and the img element.
Here is an illustrative before and after. BASE64_BYTES_HERE is a placeholder, not a working image, and the hosted address is fictitious.
Before:
<img src="data:image/png;base64,BASE64_BYTES_HERE" alt="Quarterly sales chart" width="640" height="360">
After:
<img src="https://example.com/images/quarterly-sales-chart.png" alt="Quarterly sales chart" width="640" height="360">
Replace the entire src value, from data: up to the closing quote. Leave the alt text alone, because it describes the image for people who cannot see it and applies to both versions. Keep correct width and height values as well, since they let the browser know the image’s proportions before it loads.
Also remember that exported markup is usually a fragment. You will not see a doctype, head or body around it, and the guide on WYSIWYG HTML download missing doctype, head and body explains why. That matters because the fragment is meant to be pasted into a larger page, not opened as a complete document.
Portability Versus Size: What Each Option Costs
Base64 represents every three bytes of image data as four text characters, with possible padding and the data:image/png;base64, prefix on top. The text is therefore roughly a third longer than the binary image it represents. In exchange, the image needs no separate address and no separate request. A hosted URL does the opposite: it shortens the HTML, adds a request for the image, and creates a dependency on whoever serves it.
| Question | Data URL in src | Hosted HTTPS URL in src |
|---|---|---|
| Where are the image bytes? | Inside the HTML fragment | On a separate host |
| How long is the fragment? | Long, because of the encoded text | Short, only an address |
| Separate image request? | No, for that image | Yes |
| What can break it? | A CMS or policy that strips or blocks data: images | A moved, deleted, private or blocked image URL |
| Caching | Travels with the HTML, not cached on its own | Can be reused if the host’s HTTP caching allows it |
Whether the hosted image is actually reused from cache depends on HTTP caching behavior, which MDN describes in its Cache-Control reference. I would not assume it is, and I would not treat a shorter fragment as a faster page.
One more distinction: minifying markup is a different job. The HTML Minifier works on markup, and I would not expect it to move image data out of src for you. Replacing the value is a manual edit, which the next section walks through.
How to Replace Base64 Image src With Hosted Image URL in HTML Export, Step by Step
- Keep copies. Save the exported fragment and the original image file before you change anything.
- Host the image. Upload it to a location intended for public reading and copy the direct HTTPS address of the image file itself, not a gallery page or share page. Open that address in a private window. You should see the image, not a login page or an error.
- Open the fragment in the HTML Code Editor. Paste the exported markup and find the
imgelement. The very longdata:image/...;base64,...value is easy to spot. - Swap the value. Select everything between the quotes of
srcand type the HTTPS address. Do not touchalt,widthorheightunless they were wrong. - Check the live preview. The HTML Code Editor shows a sandboxed preview as you type. If the image does not appear, check the address first, then whether the host allows other sites to load the file.
- Copy into the CMS. Paste the edited fragment into the destination, save, and then run the published-page checks below.
This works because the browser reads the src value and resolves it the same way whether it is a data URL or an address. You are changing where the bytes come from, not how the element behaves.
Treat the preview as an intermediate check only. The site describes the HTML Code Editor as having syntax highlighting, auto-closing tags, a sandboxed live preview and beautify or minify, but no validation. A clean preview does not prove that the markup is valid, that the image will stay reachable, or that your CMS will keep the attribute.
Check srcset, picture and the Visual Editor Before You Trust the Edit
Changing src does not always change what the reader sees. If the element also has a srcset attribute, or sits inside a picture element with source children, the browser may select another candidate instead. The HTML Standard section on images defines how those sources are chosen. Search the fragment for srcset and <picture> and update every candidate that still holds the old data URL.
The second risk is a round trip through a visual editor. If you paste your edited fragment back into a WYSIWYG editor, or press Apply Changes in its Source view, the markup is converted back through the visual editor, and anything it does not represent can be removed or rewritten. The guide on why WYSIWYG source view removes class and ID attributes shows that behavior with a small example. A manual source edit may not be preserved, so I would finish the edit in the HTML Code Editor and go straight to the CMS, then inspect the saved markup.
If you must go back through the visual editor, open the source afterward and confirm the src still holds your HTTPS address and the alt text is intact.
Published-Page Checklist: Confirm the Image After the CMS Saves It
The editor preview and your CMS can apply different policies and rendering conditions, so the real test happens on the published or previewed page.
- Confirm the saved src. View the page source or the CMS code view and check that your intended address is still in
src. - Open the page as a reader. Use a private window without editor credentials, so you see what visitors see.
- Open the image address directly. It must return an image, not a login page, redirect loop or error.
- Check the rendered image and its alternative text. Make sure the image displays at a sensible size and the
alttext still describes it. - Check the content security policy. A policy can limit which sources images may load from, and the
img-srcdirective in the Content-Security-Policy reference covers both hosted origins anddata:images.
The same logic applies if you kept the data URL. Keeping it does not override a CMS rule that removes it or a policy that blocks data: images, so the published-page check is still needed. If the destination is an email, read HTML Email Editor in the Browser for a safer draft and export workflow, since email destinations have their own constraints.
Also remember that a hosted image must stay accessible after publication. If you delete, rename or make the file private later, every page that points to it will show a broken image.
Short Decision Checklist
Answer these in order and stop when one gives a clear result.
- Does the destination CMS keep
data:images when you save? If not, use a hosted URL. - Must the fragment work with no outside dependency? If yes, keep the data URL.
- Is the encoded text making the markup hard to review or edit? If yes, a hosted URL is easier to read.
- Will the image address stay public and stable? If you cannot promise that, keep the data URL or host it somewhere you control.
- Does your page policy allow the chosen image source? If not, change the source or the policy, not just the markup.
Frequently asked questions
Does a Base64 image make my page slower?
Not necessarily, and a hosted URL is not automatically faster. Base64 text is longer than the binary image and arrives with the HTML, while a hosted image needs a separate request that may be cached. The result depends on the image, compression, caching and page context, so measure the real page instead of assuming.
Can I change only the src and leave the rest of the img tag?
Yes, in the simple case. Replace only the src value and keep alt, width and height if they are correct. First check whether the element has srcset or sits inside a picture element, because the browser may then choose a different source and the old image can still appear.
Will the WYSIWYG editor keep my manual source edit?
Do not assume so. Applying source changes converts the markup back through the visual editor, which can remove or rewrite markup it does not represent. Finish the edit in the HTML Code Editor, copy it to the CMS, and inspect the saved source to confirm your src survived.
Does the HTML Code Editor tell me if my image URL is valid?
No. The editor offers a sandboxed live preview but no validation. If the image shows, the address probably loads in that preview, but that proves neither valid HTML nor CMS behavior. Open the URL directly and check the published page as a reader.
What if the hosted image shows a login page or a broken icon?
The address is probably not a direct, public image URL. Use the link to the image file itself, not a share or gallery page, and test it in a private window. Also check that the host allows other sites to load the file, and that the file has not been moved or made private.
Why does the old image still appear after I changed src?
Look for srcset or a picture element with source children that still hold the old data URL, since the browser may select them. Other causes are a CMS that kept its own copy of the markup, or a cached page. Check the saved source first.
Can a content security policy block my image either way?
Yes. A policy can restrict image sources through the img-src directive, which may allow or disallow data: images and specific hosted origins. If an image works in the editor preview but not on the published page, compare the page’s policy with the source you chose.
Next steps
To replace base64 image src with hosted image URL in HTML export, swap the whole data: value for a public HTTPS address, keep the alt, width and height attributes, and check for srcset or picture sources that may still use the old data. Keep the data URL instead when portability matters and the CMS accepts it. Your next step is to paste one exported fragment into the HTML Code Editor, make the edit on a copy, check the preview, and then confirm the saved page in a private window.
Related tools and resources on HTML Editor Online:
- WYSIWYG HTML Editor
- WYSIWYG HTML Download Missing Doctype, Head and Body: Why It Happens
- HTML Minifier
- HTML Code Editor
