What is the fundamental difference between window and document?
Your mental model of the browser runtime layers.
Window is the browser tab and global scope; document is the object-oriented DOM representation of the loaded page.
What's really being asked
This tests whether you view the browser environment as a layered architecture or as a single flat global namespace. At a senior level, interviewers want to hear that window represents the browser tab and the global execution context, while document is the object-oriented DOM representation of the loaded page. The distinction matters because it reveals your understanding of scope lifecycles, security boundaries, and how browser engines separate the container from the content.
The full answer
First, window is the global object for the browser tab; it holds browser-level APIs like location, history, and navigator, and it serves as the global this value. Second, document is the root of the DOM tree; it is the programming interface that represents the page structure, style, and content as nodes and objects, allowing scripts to query and manipulate the page. Third, the document lives inside the window; when you navigate, the window object persists but the document object is replaced with a new one. Fourth, in multi-frame contexts, each frame has its own window and document pair, so the one-to-one relationship is per browsing context, not per browser process.
The mistakes people make
A red flag is saying they are basically the same or that document is just a property of window with no deeper meaning. Another weak answer is listing methods like alert or setTimeout on window without explaining why they live on the container rather than the document. Some candidates describe document as only the HTML source string rather than the in-memory object-oriented representation. Confusing the global scope with the DOM root signals a shallow mental model of the browser runtime.
What usually comes next
An interviewer might ask where global variables live, which is on window, and why polluting it affects performance. They might ask what happens to event listeners attached to document versus window during navigation. They could also ask how iframes relate to window and document, or why the DOM is not part of the core JavaScript language but rather an API provided by the browser.
A concrete example
Imagine a single-page application that uses window.addEventListener for scroll events and document.querySelectorAll for content updates. If the user navigates to a new route, the document object is rebuilt, so all document-level listeners and cached node references must be re-established, but the window object and its scroll listener remain intact. This separation is why attaching heavy state to window leaks across soft navigations while attaching it to document scopes it to the current page content.
Interview question
During a normal page navigation in the same browser tab, which object is replaced while the other persists?
- a.Neither object is replaced; both remain intact for the lifetime of the tab.
- b.Only the document object is replaced; the window object persists as the tab container.Correct
- c.Both window and document are replaced because they both represent the loaded page.
- d.Only the window object is replaced because it holds the page-specific content.
Why? this is the answer
The window object represents the browser tab and global execution context, so it persists across navigation, while the document is the in-memory DOM representation of a specific page and is rebuilt. Claiming both are replaced is a common misconception that treats window and document as the same page-level entity rather than as container versus content.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles