path/case Converter

What is path/case?

path/case writes identifiers in lowercase with forward slashes separating words. It's a structural convention more than an identifier-formatting convention — slashes represent hierarchy, and the format is most useful when each "word" actually represents a distinct level of nesting (a directory, a route segment, a resource).

The forward slash isn't arbitrary. It's the universal path separator on Unix systems and the standard URL path separator in HTTP. When you write users/profile/settings, the format is self-documenting: anyone familiar with URLs or filesystems reads it as "the settings section of the profile area of the users module."

path/case rarely appears as a programming language identifier. The forward slash is reserved for division in most C-family languages and can't appear in variable names. Instead, path/case lives in string contexts: URL routes, file paths, S3 object keys, container image names, CMS content paths. These are places where the hierarchy needs to be visible in the text representation.

When to use path/case

• URL routes in web frameworks. Every modern framework uses path/case for routes: Express (/users/:id), Django (users/<int:id>/profile/), Rails (resources :users generates path/case paths), FastAPI (/users/{user_id}/orders), Laravel, ASP.NET — all of them.
• REST API endpoints. Nouns at each path segment, separated by slashes. GET /users/{id}/orders. The convention follows from REST's resource-oriented design.
• File paths. Source code organization mirrors URL structure in modern applications: src/components/ui/button.tsx, docs/guides/getting-started.md.
• S3 object keys. S3 keys are flat strings but conventionally use slashes to simulate a hierarchical directory structure. uploads/2024/january/photo.jpg. S3 even has API methods that treat the slash as a prefix delimiter for "directory" listings.
• Container image names. Docker, Kubernetes, and OCI registries use path-style names: registry.example.com/myorg/myapp:v1.2. The slashes organize images by registry, namespace, and image name.
• CMS content paths and slugs. WordPress permalinks, Drupal aliases, headless CMS routes — all path-based.
• Configuration file paths in tools like Vault and Consul. secret/prod/database/password. The slashes navigate a hierarchical key-value store.
• Logical resource paths in feature flags and A/B testing. checkout/payment/new-flow. The hierarchy organizes flags by product area.

How path/case conversion works

1. Tokenize the input. "User Profile Settings" → ["User", "Profile", "Settings"].
2. Lowercase each token. ["user", "profile", "settings"].
3. Join with forward slashes. "user/profile/settings".
4. Decide whether to add a leading slash. Some contexts (URL absolute paths) want one; others (file paths, S3 keys) don't. Our converter doesn't add a leading slash — that decision is left to the user since it depends on context.

Within-segment formatting

The interesting question is what to do about multi-word names that should remain as a single segment. If your route includes "user profile settings", should that be three separate segments (users/profile/settings) or one kebab-case segment (user-profile-settings)?

The answer depends on intent. If the words represent distinct hierarchical levels — a collection of users, with profile relations, with settings within each — use separate segments. If the words just describe a single resource — like a blog post title — use kebab-case within a single segment.

Mixing the conventions is normal: /api/v1/user-profiles/active uses path/case for the API versioning hierarchy and kebab-case within the resource name.

Security: path traversal

When accepting user input that becomes part of a path, sanitize for traversal attacks. A user-supplied "name" of ../../etc/passwd can escape the intended directory if naively concatenated. The conversion to path/case doesn't sanitize — it only formats. Validate that path components don't contain .., leading slashes, or null bytes before using them in real file or URL paths.

Trailing slashes and canonicalization

URLs are ambiguous about trailing slashes: /users and /users/ are technically different URLs but usually represent the same resource. Web servers handle this with redirects (Apache and Nginx default to redirecting between the two forms). Our converter doesn't add a trailing slash — pick whichever style your framework expects and apply consistently.

Worked examples

Related case formats