107

I'm afraid it might be impossible but is there a way to change the hash value of a URL without leaving an entry in the browser's history and without reloading? Or do the equivalent?

As far as specifics go, I was developing some basic hash navigation along the lines of:

//hash nav -- works with js-tabs
var getHash = window.location.hash;
var hashPref = "tab-";
function useHash(newHash) {
    //set js-tab according to hash
    newHash = newHash.replace('#'+hashPref, '');
    $("#tabs li a[href='"+ newHash +"']").click();
}
function setHash(newHash) {
    //set hash according to js-tab
    window.location.hash = hashPref + newHash;

    //THIS IS WHERE I would like to REPLACE the location.hash
    //without a history entry

}
    // ... a lot of irrelavent tabs js and then....

    //make tabs work
    $("#tabs.js-tabs a").live("click", function() {
        var showMe = $(this).attr("href");
        $(showMe).show();
        setHash(showMe);
        return false;
    });
    //hash nav on ready .. if hash exists, execute
    if ( getHash ){
        useHash(getHash);
    }

Using jQuery, obviously. The idea is that in this specific instance 1) making the user go back over every tab change could effectively 'break the back button' by piling up needless references, and 2) not retaining which tab they're currently on if they hit refresh is an annoyance.

  • Why do you want to change hash if you don't want to keep history track? :| – Ionuț Staicu Feb 22 '10 at 06:29
  • 11
    Because on refresh it would be best to present the user with the tab they were on, but since they may be flipping back and forth between tabs, it would glut their history with entries unnecessarily, making the back button actually less useful. This is just an example, though--it could be for any time you need to save a temporary state but don't want to rely on cookies or fill the user's temp file with them. When you refresh, the js content is as you left it--you haven't left the page, and it's not a jump-to point or a psuedo-page, so the history entry can only interfere with standard nav. –  Feb 22 '10 at 11:16

4 Answers4

112

location.replace("#hash_value_here"); worked fine for me until I found that it doesn't work on IOS Chrome. In which case, use:

history.replaceState(undefined, undefined, "#hash_value")

history.replaceState() operates exactly like history.pushState() except that replaceState() modifies the current history entry instead of creating a new one.

Remember to keep the # or the last part of the url will be altered.

Lucia
  • 13,033
  • 6
  • 44
  • 50
  • 3
    Totally the way to go for modern browsers; be aware of the [partial support](http://caniuse.com/#feat=history) session history management has though. – Matt Oct 19 '14 at 16:43
  • I'm confused as to how to use this. Should I still use `window.location.hash = 'my-hash';` followed by `history.replaceState(undefined, undefined, "#my-hash")`? – Bram Vanroy May 14 '15 at 15:18
  • 2
    @BramVanroy No, using the latter is sufficient. – Lucia May 15 '15 at 00:29
  • 2
    Unless you use :target selectors ... then history functions are useless, as that part of the spec (css interaction with history ops) seems to be not defined currently, and style does not get recomputed on history replace by most/all browsers. – morphles Jul 27 '16 at 05:38
  • @Luxiyalu, How does `history.replaceState` differ from `location.replace`? – Pacerier Oct 17 '17 at 09:29
  • 1
    Just as a note: `history.replaceState()` and `location.replace()` still create entries in Chrome history which can be considered unacceptable in some cases: https://stackoverflow.com/questions/26793130/history-replacestate-still-adds-entries-to-the-browsing-history – Grief Mar 26 '19 at 01:11
  • 4
    Note: interestingly, `history.replaceState(...)` does **not** trigger a `window.onhashchange` event. `location.replace` does. Weird, right? – Matt Aug 19 '20 at 23:46
  • 1
    @Matt that is mentioned in [the spec](https://html.spec.whatwg.org/multipage/history.html#url-and-history-update-steps): *Since this is neither a navigation of the browsing context nor a history traversal, it does not cause a hashchange event to be fired.* – ZachB Apr 20 '21 at 21:13
  • *'location.replace("#hash_value_here"); worked fine for me until I found that it doesn't work on IOS Chrome'* - Not sure what this referred to in 2014 but it's supported by all browsers today https://caniuse.com/mdn-api_location_replace – Yarin Mar 24 '23 at 16:54
  • A key difference is that this will add entries to Chrome's "Browser History" page, while [location.replace(...)](https://stackoverflow.com/a/6945614/165673) does not. – Yarin Mar 24 '23 at 17:01
  • I had to use it like this: `history.replaceState({}, '', anchor)` because it was not accepting undefined as the second argument. – Georgi Georgiev Apr 12 '23 at 06:52
104
location.replace("#hash_value_here");

The above seems to do what you're after.

Matt
  • 3,617
  • 2
  • 27
  • 39
  • 4
    This is it. And if you have uri segments, location.replace(window.location + "#hash") will preserve them. – tedders Jan 17 '12 at 16:00
  • 7
    Seconding this method, much cleaner, wish it was marked as the correct answer. – joeellis Mar 02 '12 at 16:45
  • Works for me in Chrome and Firefox. Note that it still inserts the history item in IE6 (see: http://splintor.wordpress.com/2007/04/12/locationreplace-and-back-button-bug-in-ie/) – jdeuce Jul 23 '12 at 18:22
  • 15
    `window.location.replace(('' + window.location).split('#')[0] + '#' + hash);` to just update the hash – johnstorm Nov 27 '12 at 20:10
  • Had to use @johnstorm's solution to handle changing hash of iframe w/o logging to history. – Dan Jan 30 '13 at 19:30
  • @johnstorm for which browser did you need that? Matt's solution worked just fine in Chrome27 on Win7 – Jörn Berkefeld Jun 17 '13 at 15:20
  • Finally saw this, marked as correct answer. I think it could use an updated answer in terms of the HTML5, right? –  Aug 01 '13 at 19:10
  • 1
    I'm testing it in Chrome 30 under Windows 8, if I go to Chrome History and select "More from this site" under my test url, I can see all the hashes that were added with this method. – TechAurelian Oct 08 '13 at 12:14
  • I don't think location.replace(url) is a solution if you need to load/change frames with different origins. Frames are blocked. – Luis A. Florit Dec 03 '16 at 15:20
  • 2
    Beware that location.replace('#hash_value_here') only changes the hash fragment and not the path, so it doesn't trigger a page load.... Except when the document contains a base tag: `` If it does contain a base tag, then when you use the replace method with just a leading `"#hash_value_here"` it actually will be as if you said `location.replace('http://example.com/#hash_value_here'). This seem obvious when you read it here, but is a gotcha when you're on a page with a path fragment and don't realize base is set. – Tyler Kasten Jun 08 '17 at 23:05
  • be careful with iframes, you need to specify the page too at the "replace", not just the # part – George Birbilis Feb 08 '21 at 17:42
  • A key difference is that this will not add entries to Chrome's "Browser History" page, while `history. replaceState(...)` does. See https://stackoverflow.com/a/75836407/165673 – Yarin Mar 24 '23 at 17:00
6

Edit: It's been a couple years now, and browsers have evolved.

@Luxiyalu's answer is the way to go

--Old Answer--

I too think it is impossible (at this time). But why do you need to change the hash value if you are not going to use it?

I believe the main reason why we use the hash value as programmers is to let the user bookmark our pages, or to save a state in the browser history. If you don't want to do any of this, then just save the state in a variable, and work from there.

I think that the reason to use a hash is to work with a value that is out of our control. If you don't need it, then it probably means you have everything under your control, so just store the state in a variable and work with it. (I like repeating myself)

I hope this helps you out. Maybe there's an easier solution to your problem.

UPDATE: How about this:

  1. Setup a first hash, and make sure it gets saved in the browser history.
  2. When a new tab gets selected, do window.history.back(1), that will make the history go back from your first init hash.
  3. Now you set the new hash, therefore the tabbing will only make one entry in the history.

You'll probably have to use some flags, to know if the current entry can be "deleted" by going back, or if you just skip the first step. And to make sure, that your loading method for the "hash" doesn't execute, when you force the history.back.

Community
  • 1
  • 1
guzart
  • 3,700
  • 28
  • 23
  • It's very possible there's something basic I'm missing (exhaustion's a nice excuse, I'll go with that) but are you saying I can set a variable that will retain its changed value on reload? Besides with a cookie? (Cookies seem overkill, somehow..) Maybe that's what wasn't clear. I will be using the hash value--particularly on reload. Thanks for responding! –  Feb 21 '10 at 07:55
  • To clarify my clarification: if the user hits reload. That's what the hash is for. I'm still trying to avoid reload in their normal use (changing/clicking tabs). –  Feb 21 '10 at 07:58
  • Ok, so you will be using some values for info after reloading. Well unfortunately, the hash value will get picked by some browser's history. Sorry to say this, but from my exp, cookies are your best bet. If you want something that the browser history doesn't detect, but to retain after reload, unfortunately, cookies. If the user was clicking a link, then you could setup the link to be a query (`?mystate=greatness`), even though it doesn't need to be ajax, you could save info for the javascript to read when initializing the request. – guzart Feb 21 '10 at 08:05
  • Yes, the hash is for saving the user's info after hitting reload, but the problem for you situation, is that some browsers will save those changes in the history, that's just the way they work... :( – guzart Feb 21 '10 at 09:22
  • Yep, think you're right. Ah well. (Would love to be proven wrong by some other method or something.) –  Feb 22 '10 at 11:18
  • I was thinking that you could use the hash, then check the history, and if it was added remove it. But after some research, it seems that JS access to the `history` is limited for security reasons. So there is no way to remove info saved in the history. – guzart Feb 22 '10 at 21:37
  • Agh, okay. Got too excited and started testing the wrong stuff. This won't work because refresh doesn't retain the tab state, which negates the point of using the hash to begin with. Very good idea though. Sad. Doesn't seem possible. –  Feb 23 '10 at 00:30
  • Maybe that is browser specific. I tried in Firefox 3.6, Chrome 3.0.195, IE 8.0.76, Safari 4.0.4, Opera 10.10 and they all retain the hash after I hit refresh. – guzart Feb 23 '10 at 00:44
-2

You can always create an event listener to catch click events on the hyperlink and in the callback function put e.preventDefault(), that should prevent the browser from inserting it into the history.

Ayman Farhat
  • 2,010
  • 3
  • 17
  • 16