What's the difference between window.location and document.location?

Question

What's the difference between window.location and document.location? Should both of them reference the same object?

Impartible

For a use case showing their difference, see https://mcmap.net/q/36258/-what-39-s-the-difference-between-window-location-and-document-location – Sapphira

A good read can also be found here: html.spec.whatwg.org/multipage/… Especially the warning given ("The Location exotic object is defined through a mishmash of IDL, invocation of JavaScript internal methods post-creation, and overridden JavaScript internal methods. Coupled with its scary security policy, please take extra care while implementing this excrescence.") is note-worthy IMHO. – Dicks

Answer 1

According to the W3C, they are the same. In reality, for cross browser safety, you should use window.location rather than document.location.

See: http://www.w3.org/TR/html/browsers.html#dom-location

Appanage

Downvoted. Answer contradictory. It boldly says they are same, then describes the differences in lighter text. They are decidedly not same. – Stare

C'mon trigger-happy down-voters, lighten up a bit. For the most part, they behave similarly CONSIDERING THE CAVEAT SPECIFIED by rahul. Let's not nail him on semantics. A little philadelphia, gentlemen. I, for one, found his answer fully satisfying. +1 (Christoph's should be the accepted answer, but rahul's is acceptable -- at the least, not worthy of down-vote.) – Custodial

-1 for recommending a best practice (always using window.location) without providing any justification for it. If you won't provide the justification, why should anyone take your advice? Christoph's answer is far more useful in this regard. – Tailrace

+1 but also see the answers by Phil Hamer and Christoph below, they add essential background info and caveats to fully understand the issue. – Margitmargo

Answer 2

The canonical way to get the current location object is window.location (see this MSDN page from 1996 and the W3C draft from 2006).

Compare this to document.location, which originally only returned the current URL as a string (see this page on MSDN). Probably to avoid confusion, document.location was replaced with document.URL (see here on MSDN), which is also part of DOM Level 1.

As far as I know, all modern browsers map document.location to window.location, but I still prefer window.location as that's what I've used since I wrote my first DHTML.

Vikiviking

if you use window.location , isnt it equally valid to just use location ? – Proselyte

@Proselyte It is -- in the context of a script in [at least] a HTML document, the global object where all defined variables become properties, is the window object. Thus, any variable or function you define at the top level of your script, is a property of the object referenced by window, which happens to be the global object. Global object is implied when absent like window. -- thus location is interpreted to be window.location. Caveats -- f.e. if(an_undefined_variable) will throw an error if variable wasn't defined -- if(window.an_undefined_variable) won't. – Pentamerous

@commonpike, yes, so long as you are in a standards-compliant browser environment and there isn't a different variable location in a local scope. – Xmas

Answer 3

window.location is read/write on all compliant browsers.

document.location is read-only in Internet Explorer (at least), but read/write in Gecko-based browsers (Firefox, SeaMonkey).

Quadrangular

I can't reproduce the claim that document.location is read-only in IE. I can successfully assign to it in IE 10, 9, 8 and 6 (using VMs from modern.ie). – Tailrace

Answer 4

document.location was originally a read-only property, although Gecko browsers allow you to assign to it as well. For cross-browser safety, use window.location instead.

Read more:

document.location

window.location

Scheming

Answer 5

Interestingly, if you have a frame, image, or form named 'location', then 'document.location' provides a reference to the frame window, image, or form, respectively, instead of the Location object. Apparently, this is because the document.forms, document.images, and window.frames collection name lookup gets priority over the mapping to window.location.

<img name='location' src='location.png'>

if (document.location.tagName == 'IMG') alert('Hello!')

Carolinian

There is no priority, it is simply overwritten – Sapphira

No, it's not overwritten. It's shadowed, so Phil is right about element taking precedence during property resolution. – Sherrellsherrer

@kangax, Seems like you are right: jsfiddle.net/uL4ysszr . But how reliable is this behavior? Is it sufficiently cross-browser? – Sapphira

I think it's pretty cross-browser, unfortunately. Don't have time to check but IIRC you should be able to find this behavior spec'd in HTML5. – Sherrellsherrer

Just tested this (October 2016). It appears that window.location and document.location cannot be shadowed in Chrome or Firefox. – Septime

@Mr.Llama You are right. It appears all modern browsers no longer behave in the way I described above. It seems to be due to giving document.location the "Unforgeable" attribute. Relevant Chromium change: src.chromium.org/viewvc/blink?view=revision&revision=189862 And Firefox bug: bugzilla.mozilla.org/show_bug.cgi?id=1133760 – Carolinian

Answer 6

As far as I know, Both are same. For cross browser safety you can use window.location rather than document.location.

All modern browsers map document.location to window.location, but I still prefer window.location as that's what I've used since I wrote my first web page. it is more consistent.

you can also see document.location === window.location returns true, which clarifies that both are same.

Man

Answer 7

document.location === window.location returns true

also

document.location.constructor === window.location.constructor is true

Note: Just tested on , Firefox 3.6, Opera 10 and IE6

Unguentum

@Sapphira Why? For objects, === and == are equivalent. – Tailrace

@MarkAmery, That's wrong and can be easily demonstrated: "abc" == new String("abc") returns true while "abc" === new String("abc") returns false. – Sapphira

@Sapphira Okay, let me state that slightly more rigorously and less ambiguously: when comparing two objects with each other (rather than just an object with anything), == and === are equivalent. See the spec sections 11.9.3 and 11.9.6. For non-null, non-undefined, non-number, non-bool, non-string values with the same type, == behavior is governed by 11.9.3 part 1f, and === behavior by 11.9.6 part 7, which identically read Return true if x and y refer to the same object. Otherwise, return false. – Tailrace

@MarkAmery, There is no guarantee that both document.location and window.location are pointing to objects. You are missing the whole point of triple equals; using 2 equals does not prove that they are the same obj. We should use 3 equals and not 2 equals because 2 equals will give us a false positive. On a browser whereby document.location is a URL string equal to window.location.toString(), Then document.location==window.location will return true while document.location===window.location will return false. – Sapphira

@Sapphira Aha - I get it at last. You are quite correct, at least as far as the document.location === window.location comparison goes. The fact that the .constructor comparison is thrown in too means, I think, that this answer is still sound, but using === would simplify the reasoning. – Tailrace

@MarkAmery, It will still fail and give false positives on a browser that allows overriding of .constructor property of a String or Number or Boolean instance. In short, YOU's code may work, but it's definitely not cross browser, and therefore it doesn't prove what it's supposed to prove. – Sapphira

when it comes to testing you need to stick with the same one? – Wellnigh

Answer 8

Yes, they are the same. It's one of the many historical quirks in the browser JS API. Try doing:

window.location === document.location

Vagus

Answer 9

window.location is the more reliably consistent of the two, considering older browsers.

Readymade

Answer 10

It's rare to see the difference nowadays because html 5 don't support framesets anymore. But back at the time we have frameset, document.location would redirect only the frame in which code is being executed, and window.location would redirect the entire page.

Lixiviate

Answer 11

document.location.constructor === window.location.constructor is true.

It's because it's exactly the same object as you can see from document.location===window.location.

So there's no need to compare the constructor or any other property.

Eidolon

Answer 12

At least in IE, it has a little difference on local file:

document.URL will return "file://C:\projects\abc\a.html"

but window.location.href will return "file:///C:/projects/abc/a.html"

One is back slash, one is forward slash.

Plan

Answer 13

Well yea, they are the same, but....!

window.location is not working on some Internet Explorer browsers.

Edaphic

Answer 14

I would say window.location is the more reliable way of getting the current URL. Following is the difference between the window.location and document.url that came in front in one of the scenarios where I was appending hash parameters in the URL and reading it later.

After adding hash parameters in the URL.

In an older browser, I was not able to get the hash parameters from the URL by using document.url, but when I used window.location then I was able to get the hash parameters from the URL.

So it's always better to use window.location.

Humanize

-1. The question didn't even mention document.URL - it was about window.location and document.location. Also, document.url doesn't exist = it should be uppercase. – Tailrace

Answer 15

I prefer using document.location, even though location, document.location, and window.location returns same object.

Reasons for using document.location are:

1. Browser compatibility section of window.location mentions

Before Firefox 57, single quotes contained in URLs were escaped when accessed via URL APIs. See bug 1386683.

2. Browser compatibility section of document.location mentions

Full support.

3. Mdn location reference uses document.location in their examples.

   // location: https://developer.mozilla.org:8080/en-US/search?q=URL#search-results-close-container
   const loc = document.location;
   console.log(loc.href);      // https://developer.mozilla.org:8080/en-US/search?q=URL#search-results-close-container
   console.log(loc.protocol);  // https:
   console.log(loc.host);      // developer.mozilla.org:8080
   console.log(loc.hostname);  // developer.mozilla.org
   console.log(loc.port);      // 8080
   console.log(loc.pathname);  // /en-US/search
   console.log(loc.search);    // ?q=URL
   console.log(loc.hash);      // #search-results-close-container
   console.log(loc.origin);    // https://developer.mozilla.org:8080
   
   location.assign('http://another.site') // load another page
   

Electrify

Answer 16

tl;dr They are virtually always the same. Prefer window.location.

The Document object's location getter steps are to return this's relevant global object's Location object, if this is fully active, and null otherwise.

The Window object's location getter steps are to return this's Location object.

https://html.spec.whatwg.org/multipage/nav-history-apis.html#dom-location

When are they different? If the document is not fully active. For example:

const iframe = document.createElement("iframe");
document.body.append(iframe);
const { contentDocument, contentWindow } = iframe;
iframe.remove();
contentWindow.location; // not null
contentDocument.location // null

Xmas

Answer 17

Despite of most people recommend here, that is how Google Analytics's dynamic protocol snipped looked like for ages (before they moved from ga.js to analytics.js recently):

ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';

More info: https://developers.google.com/analytics/devguides/collection/gajs/

In new version they used '//' so browser can automatically add protocol:

'//www.google-analytics.com/analytics.js'

So if Google prefers document.location to window.location when they need protocol in JS, I guess they have some reasons for that.

OVERALL: I personally believe that document.location and window.location are the same, but if giant with biggest stats about usage of browsers like Google using document.location, I recommend to follow them.

Sweat

I didn't downvote, however, it could be because this is a really old question and your answer doesn't provide any new or valuable evidence that one is better than the other. Or, it could be because your answer suggests the opposite of the public opinion, regardless of the merit you give to what Google has done historically. Or, it could be that the downvoter just didn't like how you put emphasis on parts of your answer that don't really need emphasizing. Could be anything really. That's the beauty of anonymous voting on SO. – Laverne

Could be because Google doesn't prefer anything. One of the devs at Google wrote that code and it hopefully got reviewed by another dev or more. – Tuinal

Answer 18

Actually I notice a difference in chrome between both , For example if you want to do a navigation to a sandboxed frame from a child frame then you can do this just with document.location but not with window.location

Assai