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.
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.
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.