I have a web application which uses URLs that look like this:

(The GUID is used instead of a plain int to discourage guessing, which is all we need for now.)

The problem: that long URL frequently breaks when sent via email. It's humans sending the emails, so I can't control the formatting. Sometimes it's the sending email program at fault, sometimes the receiving, but regardless I'm spending too much time on talking people through fixing problems.

Everything has to be from this domain, so I can't use a third-party shortener. I could host my own, but that seems like a kludge.

Any suggestions?


@Sunny: Thanks for elaborating, but my situation differs from what you assume. A corporate customer (of mine) passes this URL to its employees, and they use it to get to a branded Registration page. They need to give a working email as part of registration, and that gets forwarded to the corporate supervisor.

Registration gets them access to a database, but what they see is not specific to the corporate customer. So the occasional interloper is not a big deal; when they get weeded out by the corporate supervisor, we invite them to subscribe.

@Everybody: the email breakage is not on the punctuation (?&=), but at some predetermined line-length. Surprised me, too. Note that the domain name is long, as is the path to the virtual directory, which is a part of the problem.

After reading the responses, I'm going to use base64 as a pseudo-shortener, something like:

...and see if that survives. Thanks to all.


REST-ful url like:{userName_here}

might help IMO.

If the user is not registered, this will do it & return a message confirming the fact

If the user has already been registered, there will be no action & perhaps a notification that the user has been registered can be shown.

The routing of the URL and/or validating the request etc. can be implementation detail best left to a module looking at the request pipeline...



As pointed out by @Steven below, there is an addition step involved in this solution:

When the user clicks on the REST URL, launch the confirmation/login screen with the user name pre-filled. The user can login to the account & this is confirmation that the user is valid. Till he does the first login, the status of the account can be "not confirmed" & at his first login, it can be "confirmed" without bothering if the click/request has come from the email sent and/or via a request in a web browser.

This will also ensure that it will work for authentic email account since till the user actually does a valid login, the account will not be in "confirmed" status...

It looks like the goal here is to send a random ID to ensure that the person registering actually has access to the email account. If that's so, then your otherwise reasonable solution is inapplicable.
Steven Sudit
Uhm, no, I don't think that'll help. The GUID isn't actually sensitive, it's random. Replacing it with a short integer that looks up the original GUID is self-defeating.
Steven Sudit
This method is used both for confirming registration and for resetting the password, so that's still not going to work.
Steven Sudit

There are some prepackaged URL Shorteners that you could host on your own. Here's a codeplex search
This will give you the ability to keep your short url's in house

Alternatively you could some how implement a RESTFul URL that would be a lot harder to screw up
This solution should work better than the querystring simply because what usually breaks in the email clients is the ?, the =, and the &

I personally think a RESTFul solution is best as it creates the cleanest urls that still make "some" sense.

For the reasons mentioned in response to Sunny, I don't think the first solution will help. The second might, although you might need some form of URL remapper, depending.
Steven Sudit
+1  A: 

The only alternative to installing your own shortener service (which would be the ideal solution IMO), may be base64 encoding of the whole URL (and using a shorter key). But that would increase string length by 33% (very likely to break in E-Mail clients as well), and look ugly.

I would go with building a URL shortener service that shortens URLs on demand to something like this:
Unicron, Base-64 increases length over binary. Compared to hexadecimal, it decreases length.
Steven Sudit
But you could could convert the Base-16 GUID (currently 32+4 characters) into a Base-64 GUID (22 characters). That would save 14 characters!
+1 for base64, which I had considered and then forgotten.
+3  A: 

You can at least shorten it a bit. Right now, you're send a GUID, which is a 128-bit number, in a format that is essentially hexadecimal with extra dashes. If you view the GUID as a byte array and convert it to Base64, you can cut things down a bit. Likewise, "query=academic" could be "q=a".


The GUID is currently taking up 36 characters. Converting to Base-64 cuts this down to 22, saving 14 chars. Replacing "query=academic&key=" with "q=a&k=" shaves off another 13. Cutting a total of 27 characters may well keep your URL short enough not to wrap, despite the presence of ampersands and equal signs.


One more detail: the Base-64 text is going to end with an "=", which will then be hex-encoded into "%3D". The solution is to cut that character off, because it's just padding.


With credit to the original posters, it looks like the best bet is a combination of things:

  1. Compact GUID with base-64.
  2. Shorten key names and, if possible, values.
  3. Wrap URL in angle-braces to encourage client to parse it properly.
  4. If possible, replace key names with URL-rewriting, so that it looks like a path.
Steven Sudit
it's not the length of the URL that's breaking, its the querystring parameters when copy/pasted into the email client. changing `query=academic` to `q=a` isn't going to solve the problem he's having.
Steven Sudit
+1 for the meta-summary.
This answer appears to be correct, so why was it downvoted?
Steven Sudit
+2  A: 

If you can't use a third-party URL shortener, then your only option (besides changing the URL structure, as Sunny suggested) is to surround your URL with angle brackets, like this:


Any email client that follows the guidelines found in the Uniform Resource Identifiers (URI): Generic Syntax document should display a clickable link. This is not a fool-proof solution, however, and you'll likely end up resorting to a URL shortening service or restructuring your URLs.

however true, this still leaves a lot of possibility for the end user to screw something up.
This helps. Another thing that would help is to send the message as MIME multipart/alternative with both text/html and text/plain renderings. The HTML one could then use a regular `<A href` to do the job.
Steven Sudit
@Intelekshual: +1 for something I never heard of. It won't work for this (because people won't know to copy/paste the angle brackets), but I will try it when sending automated emails.

How about replacing the GUIDS with YouTube style keys


By using base-64 strings (instead of Guids which are base-16) and dropping those pesky dashes, you can pack a decent range of unique keys into a small amount of characters.

This is old territory, and a GUID in Base-64 takes 22 chars, not the 8 you show in your example.
Steven Sudit

What about a combination of the methods described here?

Combining shorter URLs with Base64 encoding of the key would turn;key=586c70bb-5683-419c-aae9-e596af9ab66a


Much more readable, IMO. And lack of chars like ? and & reduces the risk of cut'n'paste errors.