path/case

What path/case is

path/case writes identifiers in lowercase with forward slashes separating words. The convention is specific to contexts where hierarchy maps onto a filesystem-like or URL-like structure — file paths, URL routes, REST API endpoints, content management system paths. It's less a naming convention for individual identifiers and more a structural convention for organizing related identifiers.

The forward slash isn't arbitrary. It's the universal path separator on Unix systems and the standard URL path separator in HTTP. By using it as the word separator, path/case becomes self-explanatory in any context where paths already exist.

Where path/case appears

• URL routes in web frameworks: /users/profile/settings, /api/v1/articles/published. Every modern web framework — Express, Django, Rails, Laravel, FastAPI — uses path/case for route definitions.
• REST API endpoints: GET /users/{id}/orders, POST /products/{sku}/reviews. The REST conventions place nouns at each path segment, separated by slashes.
• File paths: src/components/ui/button, docs/guides/getting-started. Code organization mirrors the URL structure in modern applications.
• CMS content paths: WordPress slugs, Drupal aliases, headless CMS routes — all use path/case for content addressing.
• S3 object keys: uploads/2024/january/photo.jpg. S3 keys are flat strings but conventionally use slashes to mimic directory structure.
• Container image tags: registry/namespace/image:tag. The path-style structure organizes images by source and purpose.

How path/case differs from other conventions

Most naming conventions are about formatting a single identifier — making "user profile name" into user_profile_name or userProfileName or UserProfileName. path/case is about formatting a sequence of identifiers that together describe a location.

In /users/profile/settings, the meaningful tokens aren't "users profile settings" mashed together — they're three distinct resources arranged hierarchically. "users" is a collection. "profile" is a relation. "settings" is another relation. The slashes communicate that hierarchy.

This is why converting arbitrary text to path/case is unusual. The conversion only makes sense when the input already has implicit hierarchy — like a configuration key with dots or a snake_case identifier that represents a path.

Within-segment naming

The interesting question with path/case is how to format individual segments. If your route includes "user profile settings", do you write /user-profile-settings (single segment, kebab-case within) or /users/profile/settings (three segments)? The answer depends on whether the URL represents a single resource or a hierarchical navigation.

• Single resource with multi-word name: use kebab-case within the segment. /blog-posts/how-to-write-clean-code.
• Hierarchical resources: use separate segments. /blog/categories/programming/articles/how-to-write-clean-code.

Mixing the conventions is fine when each segment is semantically distinct. /api/v1/user-profiles/active uses kebab-case for the resource name "user-profiles" and slashes for the API versioning hierarchy.

Conversion behavior

Converting to path/case typically means lowercasing the input, replacing whitespace with slashes, and possibly removing or replacing special characters. The transformation is most useful when:

• You have a hierarchical name like "users / profile / settings" and want to normalize it to users/profile/settings.
• You're generating REST endpoint paths from a list of resource names.
• You're building file paths from category labels in a CMS.

Note that path/case is rarely the final convention for individual identifiers. It's more commonly a structural format used in combination with another within-segment convention — like kebab-case slugs nested in slash-separated routes.

The leading slash question

Absolute paths start with a slash. Relative paths don't. URLs starting with the host (like Express routes) typically start with a slash to indicate the path is rooted. Our converter doesn't add a leading slash automatically — what you do with the result depends on context. Add one when generating absolute URLs; omit it when generating file paths or relative routes.

Path traversal and security

Worth noting because it bites people: when accepting user input that becomes a path, never concatenate it directly without sanitization. A user providing ../../etc/passwd as their "username" creates a path traversal vulnerability. The conversion to path/case doesn't sanitize for security — it just formats. Always validate that path components don't contain .., leading slashes, or other navigation tokens before using them in a real path.