Why Chrome Loses What You Typed

Blaming yourself for a lost paragraph is the normal reaction, and it is worth correcting. Chrome is not forgetting your text because of a bug or a low memory setting. It is doing exactly what it was designed to do.

Understanding the design makes the fix obvious, so this is a walk through what the browser keeps, what it throws away and why those decisions were made.

What Chrome keeps

Chrome has a form filling system. It watches for fields whose purpose it can recognise, learns the values you enter and offers them back next time on the same site.

What it recognises is deliberately narrow:

• Your name, and the spelling variants of it.
• Postal addresses, in a structured format.
• Telephone numbers and email addresses.
• Organisation names, job titles and usernames.
• Payment card details, and only when you choose to save them.

These are short, structured, repeatable values. Your surname does not change between visits, so remembering it saves you typing. This is the entire philosophy of the feature.

One consequence surprises people. Because these values are saved through your Google account when you are signed in, autofill data does travel between your devices. That is worth knowing, and it is entirely different from what happens to the body of a support reply.

What Chrome discards

Everything else. A textarea holding four paragraphs of a complaint, a comment explaining a bug report, a job application cover letter, a forum post you spent an hour on: none of that is recognisable as a short repeatable value, so none of it is kept.

There is no general record of what you typed. No history entry, no cache entry, no temporary file. When the page goes away, the text goes with it.

This is a privacy decision, and a reasonable one. If every browser kept a log of every sentence typed into every form, that log would be one of the most valuable files on your machine. It would contain the contents of your messages, your applications, your medical forms and your banking details. The designers of every major browser decided that trade is not worth making, and they are right.

Not keeping your text is the correct behaviour. Being upset about it is a sign you need a backup, not a sign Chrome is broken.

What rich text editors are worse at

Chrome does not treat a contenteditable region as a form field at all. Notion, Zendesk, Salesforce, Draft.js and TipTap all build their editors this way, which means everything in the previous section applies with nothing left over.

This is why the built-in form recovery is so weak on exactly the sites where you write the most. A long answer in a textarea is at least a form field. A long answer in a rich text editor is not a form field by any measure the browser uses.

Why the back button works sometimes

Chrome keeps recently used pages in a cache so that going back feels instant. While a page is in that cache, its field values are still there, which is why the back button rescues your text on some occasions.

It stops working when the page is evicted from the cache. A heavy tab competing for memory is often enough. So is closing the tab, reloading the page or restarting the browser. Once that happens, the values are gone and the back button is just a back button.

The pattern people notice is that the rescue works for small things and fails for important things. A one-line search term survives, because you retype it in seconds. Twenty minutes of writing does not, and by then the page is long gone.

Why single page apps lose it instantly

A modern site usually never reloads the document. It swaps the contents of the page using script, and the address bar changes without a navigation. There is no previous page in the cache, because there was no previous document.

On top of that, many of these apps give every field a freshly generated identifier each time they render. Two renders later, the field you typed into no longer exists by name. Anything that identifies a field by its identifier alone is now looking for something that has been thrown away.

This is why a tool that works perfectly on an old forum can do absolutely nothing on a modern application, with no error and no visible sign of failure.

What this means for you

Nothing here is fixable inside Chrome, and there is no flag, setting or about:config value that changes it. The behaviour you are seeing is the intended behaviour.

Your options are therefore narrow and clear. Draft long text outside the browser, which works everywhere and costs nothing. Or keep a local copy as you type, in a tool that stores it on your own device and knows how to put it back into a page that is still running.

What you should not do is wait for the back button. It is a coincidence, not a mechanism.

FAQ

Related Articles