URLs Are User Interface
Most discussions of user interface focus on visual elements—buttons, menus, forms. But URLs are also interface. Users see them, share them, type them, and modify them. A well-designed URL is a usability feature.
Where Users Encounter URLs
- Browser address bar: Always visible, always editable
- Search results: Google displays URLs under each result
- Shared links: URLs in messages, emails, social media
- Printed materials: Business cards, flyers, signs
- Spoken references: "Go to example.com/contact"
The Jakob Nielsen Perspective
In 1999, usability expert Jakob Nielsen wrote "URL as UI," arguing that URLs should be:
- A form of navigation
- Readable by humans
- Hackable (editable to find related content)
- Persistent (the "cool URIs" principle)
"URLs will be with us for many years to come, so we need to design them well."
— Jakob Nielsen, 1999
Readable URLs
A readable URL tells users where they are and what they'll find—before they even click.
Good: Self-Describing
// You can tell what these pages contain: https://example.com/products/cameras https://example.com/blog/2024/url-design-guide https://example.com/help/shipping-returns https://example.com/about/team
Bad: Opaque
// These tell you nothing: https://example.com/p/38572 https://example.com/node/5847 https://example.com/index.php?id=99&cat=4&view=full https://example.com/a/b/c/d/e/f
Readability Principles
Use Real Words
// Bad /p/38572 /cat/4/subcat/12 // Good /products/cameras /products/cameras/mirrorless
Use Hyphens for Spaces
// Bad /products/digital_cameras // underscores /products/digitalcameras // run together /products/digital%20cameras // encoded spaces // Good /products/digital-cameras // hyphens
Use Lowercase
// Inconsistent (confusing) /Products/Cameras /products/CAMERAS /PRODUCTS/cameras // Good (predictable) /products/cameras
Be Concise but Clear
// Too long /our-amazing-selection-of-high-quality-digital-cameras-for-professionals // Too short /p/cam // Just right /products/professional-cameras
Predictable URLs
Predictable URLs follow patterns that users can recognize and anticipate.
Consistent Structure
// Predictable pattern: /blog/2024/01/article-title /blog/2024/02/another-article /blog/2023/12/older-post // User can guess: /blog/2024/ shows all 2024 posts // User can guess: /blog/ shows all posts
Hierarchical Logic
// Each level makes sense: / → Home /products → All products /products/cameras → All cameras /products/cameras/canon-r5 → Specific camera // Navigation up works by removing path segments
Expected Patterns
Users expect certain URLs to exist:
| Expected URL | User Expectation |
|---|---|
/about |
Company/site information |
/contact |
How to get in touch |
/help or /support |
Getting assistance |
/blog |
News and articles |
/products or /shop |
Things to buy |
/login or /signin |
Account access |
/search |
Search functionality |
/sitemap |
Site structure |
Violating these expectations frustrates users who try to navigate directly.
Hackable URLs
A "hackable" URL is one users can edit to navigate. This is a feature, not a bug.
Navigating Up
// User is at: https://example.com/products/cameras/canon/eos-r5 // User modifies URL to explore: https://example.com/products/cameras/canon → All Canon cameras https://example.com/products/cameras → All cameras https://example.com/products → All products
This only works if each path segment represents something real and navigable.
Pattern Recognition
// User notices a pattern: https://example.com/users/alice/photos https://example.com/users/bob/photos // User tries: https://example.com/users/charlie/photos // And it works! URL structure is consistent.
Query Parameter Exploration
// User sees: /products?category=cameras&sort=price // User experiments: /products?category=cameras&sort=rating → Sort by rating /products?category=cameras → Remove sorting /products?category=lenses → Change category
Date Navigation
// Archive URL pattern: /blog/2024/03/specific-post // Users can navigate to: /blog/2024/03/ → March 2024 posts /blog/2024/ → All 2024 posts /blog/ → All posts
URLs and Information Architecture
URL structure should reflect your site's information architecture—the way content is organized and related.
Flat vs Deep
// Deep hierarchy (hard to navigate) /products/electronics/computers/laptops/gaming/brand/model // Flatter structure (easier) /products/gaming-laptops/model // Balance: deep enough to organize, shallow enough to navigate
Faceted Navigation
For complex filtering, query parameters often work better than paths:
// Path-based (inflexible) /products/laptops/under-1000/gaming/dell // What if user wants gaming+business? Under 1500? // Query-based (flexible) /products/laptops?price=under-1000&type=gaming&brand=dell // Easy to add/remove/change filters
Canonical URLs
When content is accessible via multiple URLs, designate one as canonical:
// Same content, multiple URLs: /products/laptop-xyz /products?id=laptop-xyz /shop/computers/laptop-xyz // Designate one as canonical (in HTML head): <link rel="canonical" href="https://example.com/products/laptop-xyz"> // Redirect others to canonical when possible
URLs and Sharing
URLs are shared constantly. Design for sharing.
Shareability Checklist
- Readable: Can the recipient understand what it is?
- Trustworthy: Does it look legitimate (not suspicious)?
- Memorable: Could someone remember it?
- Speakable: Can it be communicated verbally?
- Copyable: No special characters that break in messages?
Social Media Considerations
// Good for sharing: https://example.com/articles/css-grid-guide // Preview shows: // Title: CSS Grid Guide // URL: example.com/articles/css-grid-guide // User knows what they're clicking
// Bad for sharing: https://example.com/articles?id=58372&view=full&ref=share // Preview shows: // URL: example.com/articles?id=58372... // User has no idea what this is
Preserving State in Shared URLs
When users share, should they share their current state?
// Search results - probably yes /search?q=css+grid+tutorial // Recipient sees same results // User preferences - probably no /products?view=grid&sort=price&show-sold-out=true // These are personal preferences, not content
Technical Constraints
Practical limitations affect URL design.
Length Limits
While the spec doesn't limit URL length, browsers and servers do:
- Internet Explorer: 2,083 characters (legacy but still referenced)
- Chrome: 32,767 characters
- Servers: Often 8,000-16,000 characters
Best practice: Keep URLs under 2,000 characters for universal compatibility.
Character Restrictions
// Safe characters (no encoding needed): A-Z a-z 0-9 - . _ ~ // Allowed but reserved (have special meaning): : / ? # [ ] @ ! $ & ' ( ) * + , ; = // Everything else must be percent-encoded: space → %20 ü → %C3%BC 中 → %E4%B8%AD
Internationalization
// Internationalized Domain Names (IDN) https://例え.jp/ページ // Displayed as above, but encoded for transmission: https://xn--r8jz45g.jp/%E3%83%9A%E3%83%BC%E3%82%B8 // Design consideration: use ASCII slugs for paths https://example.jp/articles/japanese-guide // More portable
Case Sensitivity
// Domain names: case-insensitive EXAMPLE.COM = example.com = Example.Com // Paths: technically case-sensitive (per server) /About ≠ /about // May be different resources! // Best practice: use lowercase, redirect others /About → 301 redirect → /about
URL Design Patterns
REST-Style Resource URLs
// Collection GET /products → List all products // Single resource GET /products/widget-pro → One product // Nested resources GET /products/widget-pro/reviews → Reviews for this product // Actions (traditionally via HTTP methods, not URLs) POST /products → Create product PUT /products/widget-pro → Update product DELETE /products/widget-pro → Delete product
Blog/News Patterns
// Date-based (good for news/blogs) /blog/2024/11/27/article-title // Slug-only (simpler, but less context) /blog/article-title // Category + slug /blog/tutorials/article-title
User Content Patterns
// Username in path /users/alice/photos /@alice/photos // Username as subdomain https://alice.example.com/photos
Documentation Patterns
// Versioned /docs/v2/getting-started /docs/v2/api/authentication // Latest (redirects to current version) /docs/latest/getting-started
Search and Filter Patterns
// Query parameters for filters /products?category=electronics&price=100-500&sort=rating // Clean URLs for common filters /products/electronics/under-500
Designing URLs for Your Project
Planning Questions
- What are the primary content types? Products, articles, users, etc.
- How are they organized? Categories, dates, relationships
- What will users search for? Should searches have URLs?
- What needs to be shareable? Which states need URLs?
- What's the expected lifespan? Will these URLs exist in 10 years?
Documentation
Create a URL design document:
## URL Conventions
### Products
- List: /products
- Category: /products/{category}
- Item: /products/{slug}
- Reviews: /products/{slug}/reviews
### Blog
- List: /blog
- Year: /blog/{year}
- Month: /blog/{year}/{month}
- Post: /blog/{year}/{month}/{slug}
### Users
- Profile: /users/{username}
- Settings: /settings (current user only)
Testing URLs
- Can users navigate up by removing path segments?
- Are similar content types structured consistently?
- Do URLs work when shared (no session-dependent state)?
- Are URLs readable aloud?
- Do they still make sense out of context?