Watch 10 video solutions for Encode and Decode TinyURL, a medium level problem involving Hash Table, String, Design. This walkthrough by NeetCode has 23,903 views views. Want to try solving it yourself? Practice on FleetCode or read the detailed text solution.
Note: This is a companion problem to the System Design problem: Design TinyURL.
TinyURL is a URL shortening service where you enter a URL such as https://leetcode.com/problems/design-tinyurl and it returns a short URL such as http://tinyurl.com/4e9iAk. Design a class to encode a URL and decode a tiny URL.
There is no restriction on how your encode/decode algorithm should work. You just need to ensure that a URL can be encoded to a tiny URL and the tiny URL can be decoded to the original URL.
Implement the Solution class:
Solution() Initializes the object of the system.String encode(String longUrl) Returns a tiny URL for the given longUrl.String decode(String shortUrl) Returns the original long URL for the given shortUrl. It is guaranteed that the given shortUrl was encoded by the same object.
Example 1:
Input: url = "https://leetcode.com/problems/design-tinyurl" Output: "https://leetcode.com/problems/design-tinyurl" Explanation: Solution obj = new Solution(); string tiny = obj.encode(url); // returns the encoded tiny url. string ans = obj.decode(tiny); // returns the original url after decoding it.
Constraints:
1 <= url.length <= 104url is guranteed to be a valid URL.Problem Overview: Design a service similar to TinyURL that converts a long URL into a short one and restores the original URL later. The system must guarantee that encoding and decoding are consistent and efficient.
Approach 1: Hash Map with Incremental ID (O(1) time, O(n) space)
This design stores every long URL in a hash table and assigns it a unique numeric ID. Each time encode runs, increment a counter and map that ID to the original URL. The short URL becomes something like http://tinyurl.com/{id}. For decode, extract the ID from the short URL and perform a hash lookup to retrieve the original string. Both operations run in O(1) time because they rely on constant‑time hash table access, while storage grows linearly with the number of URLs, giving O(n) space.
The key idea is separating the short identifier from the stored data. The short URL only contains a compact key, while the mapping lives in memory or a database. This approach is simple and reliable for interview scenarios and demonstrates understanding of system design basics.
Approach 2: Base Conversion (Base62 Encoding) (O(1) time, O(n) space)
Instead of exposing a numeric ID directly, convert the counter value into a Base62 string using digits, lowercase letters, and uppercase letters. For example, an integer ID like 125 becomes a short code such as cb. This reduces the URL length significantly while keeping the mapping reversible. Encoding works by repeatedly dividing the ID by 62 and mapping remainders to characters. Decoding reverses the process by converting the Base62 string back into an integer and retrieving the original URL from the hash map.
This method still uses a hash table internally but improves aesthetics and scalability of the short URL. The conversion step runs in constant time because the encoded string length is small, keeping overall complexity at O(1) time for both operations and O(n) space for stored mappings. It also demonstrates knowledge of hash functions and compact identifier generation.
Recommended for interviews: The hash map approach proves you understand the core requirement—mapping a short key to a long URL with constant‑time lookup. Interviewers usually expect the Base62 variation next because real TinyURL services avoid raw numeric IDs. Showing both designs highlights practical thinking: the first ensures correctness, while the second improves usability and URL length.
| Approach | Time | Space | When to Use |
|---|---|---|---|
| Hash Map with Incremental ID | O(1) encode, O(1) decode | O(n) | Simple implementation and common interview baseline for URL shortener design |
| Base62 Conversion with Hash Map | O(1) encode, O(1) decode | O(n) | When shorter, production-style URLs are required instead of sequential numeric IDs |