Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an Excel hyperlink problem: I click on, let's say A1, copy the link in it (, right click on hyperlink and copy that SAME URL as the link (if it is not automatically detected and changed).

When I go to click on it, I am redirected to

If I copy and paste the link directly into the browser, it works fine (i.e., I am not redirected to a different URL).

Does anyone know what's going on?

share|improve this question

migrated from Jul 4 '12 at 20:48

This question came from our site for professional and enthusiast programmers.

I ran into the same problem with a URL that requires authentication. If you click from an Excel spreadsheet to a URL that requires you to be logged in to a cookie-based session, most sites will redirect the Microsoft Discovery Agent to a login page. Unless the site is smart enough to redirect the login page request back to the original request in the case that the user is already logged in, you end up being forced to log in manually once the page loads in your real browser. The user experience is that all links appear to be logged-out. – Joe Jul 10 '13 at 4:43

11 Answers 11

The URL you're using needs some more information from a cookie to display the search results rather than the search page. Paste the URL into a different browser (or remove your cookies) and you'll get the same results.

Clicking a URL in Excel seems to open it in your default browser. But that's not really true. Before opening it in your browser, Excel first runs Microsoft Office Protocol Discovery. This uses a Windows/Internet Explorer component to determine if the URL works. (It does not identify itself as Internet Explorer, but as "User Agent: Microsoft Office Existence Discovery".) And if the results are (somehow) okay then it will open the result of that check in your default browser.

Lacking the cookies (more precisely: lacking a session), GoDaddy gives that Internet Explorer component some redirect. And the result of that is opened in your default browser. That's the URL you're seeing.

Most likely your default browser is not Internet Explorer? Then pasting the URL into IE directly and clicking it, to get the cookies, might then also make the link work from Excel. (Just for testing; it's not a permanent solution.)

You will have more luck using a URL that does not rely on some hidden information from a cookie, like

share|improve this answer
Great information, thank you. I'm seeing the same in Word when opening a link for which you must be logged in. – marcvangend Aug 11 '15 at 11:41
This should be marked as the correct answer. – Selosindis May 31 at 18:00

This is Excel fault. If you paste the link in Outlook email or WordPad and you open the link from there it will work correctly.

Excel should never create hidden session to verify the hyperlink. what's the point of it. It just needs to open it, nothing else. They use the same logic in MS Word. It doesn't work from there neither. When Excel tries to verify the link in the background, new session is created that is not authenticated so it gets redirected to login page or something. After that instead of opening the original URL in the browser, Excel is opening the redirection url. They really know how to make simple thing complicated.

share|improve this answer
It's not Excel that is creating sessions. It's the GoDaddy website that does that. Copying the URL from one browser to another will also NOT get one the search results. Using the Excel workbook on another computer will also fail. (Apart from that: indeed Excel is messing up by trying to be smart; see the other answers for more background info.) – Arjan Dec 12 '12 at 18:35

Too much here to add as a comment I'm afraid.

The initial link returns a 302 status code

From the w3c standards:

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client.

So as @xlm stated, this is GoDaddy doing a temporary redirect.

It would seem that, when called from Excel, the redirect is not always being honoured.

share|improve this answer
I'd have added this as a comment to @xlm's answer but it's too big. I realise that this isn't an answer. – Julian Knight Jul 6 '12 at 9:59

This is a Microsoft bug due to which the hyperlinks redirects to another page:

Here is the fix

Microsoft Fix it 50655

Apply fix from here:

share|improve this answer

It's definitely annoying. One workaround is to make link to a local file that redirects to the hyperlink. For example, something like:


I don't know much about HTML, but it would be nice to be able to pass an argument (ie, the URL) to this local html file.

share|improve this answer

I can replicate your problem however it's not an Excel issue. It is actually Godaddy that is redirecting you to the second link. Try pasting that link into your browser and you will see it redirect to the second one.

Notes:Tested on Excel 2007, Firefox 13.0.1

share|improve this answer
hm.. but when I paste the link into the browser I stay on the first link.. that is why it's wierd.. how is godaddy able to detect the diference between pasting the link in the url or navigating from an excel file? – Andrej Jul 4 '12 at 5:27
They aren't, basically when your browser attempts to visit the first link, their server responds by sending you to the second. It has nothing to do with Excel. I've verified this on Chrome as well. I can't reproduce the circumstances you describe where you enter it on your browser and it doesn't redirect. What browser are you using? – xlm Jul 4 '12 at 5:31
i'm using Chrome, but I see what's going on now.. the request is session based.. so when i open from another browser, i can't see the link.. and somehow the session is broken when accessing from teh excel file.. – Andrej Jul 4 '12 at 5:32
Try reproducing those circumstances again with Chrome, I'm quite sure you'll end up at the second link. Excel is just opening the link with your default browser. Also if this resolves your Q please mark it thanks! – xlm Jul 4 '12 at 5:34
sorry but it doesn't resolve the issue.. excel opens the link with chrome too, that's why it's wierd..when i paste that same link in chrome - it works.. but when i click on hyperlink it doesn't... when i open it in chrome in incognito, it also doesn't work... – Andrej Jul 4 '12 at 5:45

I had the same problem only the site I was going to included processing and retrieving data base on a date stamp. I would copy the url to a new cell. change the date. click on the new url, BUT get the old url.

However, if I ctl clicked on the new url cell, go up to the cell display window click my cursor anywhere in that window then click on a different cell the url date values change and clicking on the url gets me the right data.

All this in IE.

It appears that when you copy the url it brings the url site info with it. Not sure what magic happens when I open the cell and don't alter it, but it changes the url when you put your pointer over it. I'm a regular magnet for this kind of stuff in Excel. Probably why I don't trust it.

share|improve this answer

I found this problem crops up when the target URL is a secure site that required a login. Even though I am logged in already in a different window, it will not work properly. If I cut and paste the URL in a new tab or window, Chrome is smart enough to find that I have already authenticated and opens the new page properly. However, If I’m not logged in to the site, I will get redirected to the login page, as expected.
But when clicking the exact same URL in Excel, with the same conditions, I either get the login page only, or my remote site just tells me it is an unsupported browser.
The problem is clearly coming from Excel, because if I take that exact spreadsheet, save it as a PDF, the hyperlinks that display in the PDF work perfectly fine when clicked.
Other than fixing this obviously unintended “feature” of Excel/Office trying to verify links as others have posted, the only workaround that I found was to create a local redirect page which could take my unique parameters within the URL and open a new window as follows (thanks to others for the JavaScript code) Redirect by changing the excel hyperlink to something like, where the redirect page is on a local server you control and the parameter 12345 makes the URL redirect to the particular entry needed. For my SS with about 10000 links this works just fine.

Redirect.html is as follows.

<!DOCTYPE html>
function getUrlVars() {
    var vars = {};
    var parts = window.location.href.replace(/[?&]+([^=&]+)=([^&]*)/gi,    
    function(m,key,value) {
      vars[key] = value;
    return vars;
    var varbaseurl=[put your base url here]
    window.location = varbaseURL  + getUrlVars()["type"]
redirecting to: <p id=demo></p>
share|improve this answer

We manage to reproduce the problem and our developer findings indicate when you paste a link into Microsoft Excel, Excel prefaces the link with a byte order mark (BOM). When this link is loaded in the browser, it does not remove the BOM from the URL.

Upon loading the URL, the browser does several tests verify that the connection is secure (https) and this is failing due to the errant BOM. This ultimately causes the relay state error, since that parameter must be sent over a secure channel.

You can reproduce this problem by copying the cell and pasting it directly into firefox, thereby taking Excel out of the picture. This also fails (sometimes in a slightly different way) but suffers from the same root problem. If you remove the "https" from the pasted URL and simply retype it, you will notice that the link now works correctly.

This is a limitation in the fact that Excel stores the BOM in the URL, and the way in which the browser cannot interpret the BOM.

At the moment the only workaround we could think of is copy the URL link and paste it over to the browser and access the page.

Also, I would personally suggest you to raise a support ticket with Microsoft and I believe they might have better understanding on this issue to help you on this matter.

share|improve this answer

I solved this by doing a google search on the Url and using the google results page url for the hyperlink

e.g. for I used In opera browser with me not signed in.

share|improve this answer

I was able to investigate this further as I was trying to get an Excel workbook to link to my own web server. I noticed that clicking a link in Excel produced three queries to the server.

  1. GET HEAD (with temporary session)
  2. GET (with temporary session)
  3. GET (with real session)

But if the linked page was redirecting the user I didn't see the third GET. Instead the second GET was redirected to a new page and the session remained temporary. Which means that if the target page requires authentication the user will be redirected to a login page even if he actually is already authenticated.

This lead me to an idea to create a landing page that redirects the user to the target page if the user is authenticated. And it works. When the third GET is received the server notices that the user is authenticated and redirects to the target page. For unauthenticated user the landing page shows a link to the target page. And when the user clicks the link the user will be redirected to sign in page.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .