0

It seems like the URLs are always Base encoded yielding a short string instead. Wouldn't it be easier from a design perspective to just use a number instead? Sure your urls could be "browsed" if you do that but the same applies for a Base64 encoded number as well.

Improve this question
1

2 Answers 2

Reset to default
6

One of the design goals for a tiny url is that it be as short as possible. Base64 provides for the greatest number of different urls using the fewest possible readable characters.

Incrementing numbers are seldom used in urls for security reasons. With incrementing urls, a user or web scraper can simply add 1 to any url to get the next url in the sequence.

Improve this answer
5
  • That goal makes sense. but wouldn't a number be shorter? Base64 will always be longer than the number it is encoding - for example encoding the number 1999 yields "MTk5OQ==" which is longer than the number itself.
    – darkmoonstone
    Aug 18, 2020 at 0:04
  • 5
    @darkmoonstone, MTk5OQ== is the encoding for the ASCII string "1999", which is longer because ASCII contains 127 possible values per character and base64 only has 64. You also have the == which is just padding. The number 1999 is fP in base64, much shorter.
    – Karl Bielefeldt
    Aug 18, 2020 at 0:56
  • Thanks Karl, you are right - the Base64 encoding is indeed shorter than the decimal representation of the number.
    – darkmoonstone
    Aug 18, 2020 at 1:52
  • 9
    This doesn't answer why URL shorteners use random strings and don't just "count up" the Base64 representations. In fact, the data encoding is a completely different issue from why they don't just count up.
    – Polygnome
    Aug 18, 2020 at 7:39
  • 1
    @darkmoonstone Think of it another way: Each byte of ASCII encoded base 10 is only using 10 byte patterns (0-9), wasting the remaining 246. Each byte of ASCII encoded base 64 uses 64 byte patterns (a-z, A-Z-, _ and =), wasting "only" 192 others. On average, a Base 64 encoded integer is 1.8x (log(64) / log(10)) shorter than its decimal encoded representation.
    – Alexander
    Aug 18, 2020 at 22:06
4

Base64 allows for higher data density. For every base64 character, you get 64 possible options - compared to only 10 for numbers. To quote Karl, the number 1999 in base64 is fP, and much much shorter. This allows for more short urls to be used.

The other reason is easy scraping. If you use incrementing IDs, and get ID=7, you can reasonably guess that there's a URL at ID=6, and ID=8, and ID=5, etc. Allowing for easy guessing of IDs isn't good - while you can never prevent it, using random IDs (of which there are more of in base64) only helps protect the content of these URLs from people looking for.

There's another reason mentioned in another thread - every service has a "third user" - but you don't want the third user to know they're the third. If you give their url the id 3, it's blatantly clear no one else uses the site, not something you'd want. You could solve this by starting at, say, 1000, but then you just limit the number of valid ids even more.

Even if those aren't great reasons, there's really no reason to use an incrementing integer as an ID for a service like this.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.