Skip to content

WYSIWYG Editor Autosave Stops After Inserting Base64 Image: Why and What to Do

admin9 min read
Conceptual illustration of a WYSIWYG editor autosave stopping after inserting a base64 image because browser storage is full

If autosave goes quiet right after you insert a photo, the likely cause is that the image was embedded as base64 text inside your HTML and the next write of the draft to browser local storage no longer fits. That is a probable diagnosis, not proof for every failure. In the WYSIWYG HTML Editor on the homepage, the image toolbar embeds PNG and JPEG files in the content, and the draft is kept only in your browser. That combination explains why WYSIWYG editor autosave stops after inserting a base64 image while the photo still looks fine on screen.

The input is a draft with a large inline image. The output you want is a safe copy. While the tab is still open, use Download HTML, confirm that content.html was actually saved, and only then shrink the image or switch to a hosted one. I checked the site guidance and the MDN references on November 6, 2026.

Conceptual illustration of a visual editor draft with a large photo next to a nearly full browser storage container

Why WYSIWYG Editor Autosave Stops After Inserting Base64 Image

The editor shows a decoded picture, but the draft it saves is HTML text. When you insert a PNG or JPEG with the image toolbar, the file is embedded as base64 inside the image’s src attribute instead of being uploaded somewhere. Autosave then writes the draft to the browser’s local storage. If that write would exceed the available quota, the browser refuses it. The site documents that autosave can stop when storage is full and that it warns before you leave if the browser refuses a save.

Three consequences follow from that design:

  • A visible photo says nothing about whether the latest draft was saved. The open editor holds your content in memory, separate from what reached storage.
  • The failure can begin with the insert that pushed the draft over the limit, not with your first image.
  • Text edits made afterward may also be unsaved. Web Storage holds strings, so I assume the draft is written as one value, which means a refused write leaves the stored copy older than what you see.

Treat this as a diagnosis to test, not a certainty. Autosave can also seem missing for unrelated reasons, such as a private window or a different browser, and those are separate problems from a full quota. The checks later in this article help you tell them apart.

Conceptual illustration of a photo expanding into a long ribbon of encoded characters, representing a base64 image

How a Small-Looking Photo Becomes a Large Draft

A data URL places the file’s bytes directly in the attribute. Here is the shape of it, shortened with an ellipsis:

<img src="data:image/jpeg;base64,/9j/4AAQSkZJRg..." alt="Product photo">

Base64 is defined in RFC 4648. It represents every three bytes of binary data as four text characters, with padding at the end when needed. The data URL prefix and the surrounding HTML add more characters. As an encoding illustration only, a 3 MiB image file works out like this:

3 MiB = 3,145,728 bytes
3,145,728 / 3 * 4 = 4,194,304 base64 characters

That is about 4 MiB of text before the extra markup, roughly a third more than the file itself. It is not a prediction of how much storage the draft uses, and it is not a safe upload size, because browsers account for storage in their own ways. Several images add up, and so does the text around them.

The editor display never reveals this. It renders the decoded picture, so you cannot see the length of the src value or the size of the draft being saved. Base64 is an encoding, not compression or encryption, so it makes the data larger instead of smaller. MDN documents both the data: URL format and the FileReader.readAsDataURL() method that can produce such a string, which is why a browser can embed a picture without any server involved.

Conceptual illustration of an overfilled drawer that cannot close, representing a local storage write that does not fit

What Happens When Local Storage Refuses the Write

Web Storage keeps strings. When a write would go over the quota, setItem() can throw a QuotaExceededError. This is an illustration of the general mechanism, not the editor’s own code:

try {
  localStorage.setItem("draft", draftHtml);
} catch (error) {
  if (error.name === "QuotaExceededError") {
    console.warn("The draft did not fit in local storage.");
  }
}

MDN’s storage quota guide currently describes a 5 MiB localStorage allowance per origin. Please do not turn that number into a maximum photo size. The draft also contains text and markup, it may hold more than one image, other data from the same origin can share the allowance, and storage accounting varies with the browser and its conditions. The same guide describes much larger, separately governed quotas for other browser-storage technologies, so the small Web Storage limit is not a limit on everything a browser can store.

The practical conclusion is simple. There is no fixed number of megabytes that I can promise will work. If autosave stops after you add an image, assume the stored draft is behind what you see and secure a copy first.

Recover the Draft Before You Leave the Tab

The site stores one browser-local draft and no server backup, so an unsaved change should not be treated as recoverable once you leave. Work in this order while the content is still visible:

  1. Stay on the page. Do not close or reload the tab, click Clear, or erase site data.
  2. Click Download HTML and confirm that content.html was actually saved in your downloads folder.
  3. Open that file in a plain text viewer and check that your text and the long image data are both present.
  4. If the browser or editor warns you about a refused save, treat that warning as a sign the draft is not stored.

Know what you are getting. The download is a content fragment, not a complete webpage, and it keeps the inline image. If you wonder why the download has no doctype, head or body, that behavior is explained in a dedicated guide. When you need a standalone page, paste the fragment into the HTML Code Editor and wrap it yourself, keeping in mind that editor has a sandboxed preview but no validator.

Download TXT and Copy Text are not substitutes for this step, because they remove images. They also keep link wording without destinations, as described in the article on WYSIWYG TXT export missing link URLs. For a draft that contains a photo, Download HTML is the export that keeps everything.

Check Whether the Image Is Inline in Source

Once the download is safe, open Source to confirm the cause. Look for an image element whose src begins with data:image/png;base64, or data:image/jpeg;base64, followed by a very long run of characters. If you see that, the photo is inline and adds to the size of the draft. If the src is a short hosted address, the image is probably not the reason and you should look at other causes, such as the private window case.

Treat Source as a place to read first. The site says Apply Changes converts the markup back through the visual editor, and that step can remove unsupported markup. The guide on why WYSIWYG Source view removes class and ID attributes shows the same round trip with a small example. Inspecting is safe, but pressing Apply Changes only to have a look can rewrite your content.

Be realistic about what this check proves. Finding a data URL shows that the image is embedded. It does not prove that the data URL caused the failed save. You can gather more evidence on a copy you have already downloaded: if later edits save without a warning after you remove or replace the image, that supports the diagnosis, though it is still not proof. Browser behavior and other data in the same origin can change the outcome, so I would not rely on any single test.

Prevent It Next Time

You cannot see the draft size, so build habits that do not depend on it:

  • Use a smaller image file before inserting it. Resize or recompress the picture in your image program first. I cannot name a size that always works, because the limit depends on the whole draft and on the browser.
  • Link to a hosted image when that suits the page. A hosted URL keeps the HTML short. The exported file then needs network access to show the picture, so it is no longer self-contained offline.
  • Download HTML after significant edits. Treat autosave as a convenience, not a backup.
  • Do not expect Ctrl+S to bypass the quota. It invokes the editor’s browser-local save, so it faces the same storage limit and is not a download.

For a wider routine around browser drafts, the guide to a browser HTML email editor shows how to draft, save and export markup safely. The same habit of exporting early applies there.

Finally, remember that a smaller image reduces the risk without guaranteeing success. No resize, file size or browser guarantees that every save will work, which is why a downloaded content.html is the dependable copy.

Frequently asked questions

Is there a maximum image size that is safe to insert?

I cannot give a fixed number. The draft contains text, markup and possibly several images, other data from the same origin may share the allowance, and browsers account for storage differently. Use smaller files, and download the HTML after significant edits.

Does Ctrl+S bypass the storage limit?

No. Ctrl+S invokes the editor’s browser-local save, not a download, so it can run into the same storage limit. Use Download HTML when you need a file.

Will Download TXT or Copy Text keep my photo?

No. Both remove images, and they also keep link wording without the destination. Use Download HTML to keep the inline image.

Can I recover the draft after closing the tab?

Do not count on it. The site stores one browser-local draft and no server backup. If a save was refused, the stored copy may be older than what you saw, so download before leaving.

Does a hosted image URL make the exported HTML self-contained?

No. A hosted URL keeps the HTML short, but the image still has to be fetched from that address, so the file needs network access to show it. An inline base64 image travels inside the file but makes it larger.

Is base64 compression or encryption?

Neither. It is an encoding that represents each three bytes as four text characters, so the text is larger than the original file. It does not hide the image or reduce its size.

Does a downloaded content.html include doctype, head and body?

No. It is a content fragment, not a complete webpage. To build a standalone page, paste it into the HTML Code Editor and add the doctype, head and body yourself.

Next steps

When WYSIWYG editor autosave stops after inserting a base64 image, assume the stored draft is behind what you see. Use Download HTML while the tab is open, confirm that content.html exists, and then check Source for a long data:image value. After that, use a smaller image or a hosted one, and download after each substantial edit. Your next step: open the WYSIWYG HTML Editor, download your current draft now, and keep that file as the copy you trust.

Related tools and resources on HTML Editor Online:

Sources and further reading

Try it in your browser

Free online editors with syntax highlighting. Open one and start coding, no account needed.

All Tools