A window with
a name.
A tiny browser property with a surprisingly long memory. Read it, change it, and follow it into another document.
window.name on cross-origin navigation; some restore it when navigating back. Do not use it as a cross-origin transport. Use postMessage() with an explicit target origin and receiver validation.
Meet the window’s name
window.name is a readable, writable string. An unnamed browsing context starts with ""; an existing or explicitly named window may already have a value. Try setting and clearing this demo’s name.
Each experiment runs in its own unnamed iframe. An iframe has its own window, so these controls change that context’s name.
The document changes. The name stays.
Each link assigns a different name, then opens a new document in the same iframe. That destination reads window.name when it loads. These generated pages share the same origin.
This is a real document navigation, not a simulated result. Local Blob URLs keep the example self-contained. “Return to source” recreates the demo’s starting context.
A new tab gets its own name
Setting the source’s name does not copy it into a fresh target="_blank" tab. Open the destination and compare its empty name with the source value displayed here.
The link opens a real tab or window, according to your browser settings. A host preview that blocks new tabs may prevent this experiment. Explicitly named targets behave differently: they can select an existing named context.
Store text. Parse with care.
You can store JSON text, but window.name is still a string. Try the valid example, then introduce a syntax error. A failed parse is handled without losing the stored text.
Treat a window’s name as untrusted input. It is not a secret store, and JSON parsing does not validate the resulting data. For application state, use a mechanism designed for your navigation and persistence needs.