File-based routing generates URLs with spaces when folder names contain spaces

[yhoungdev]

Which project does this relate to?

Router

Describe the bug

When using file-based routing in TanStack Router, if a folder name contains a space, the generated route includes %20 in the URL. While technically correct, it leads to awkward and less user-friendly URLs. It might be better to disallow spaces in folder names or automatically normalize them (e.g., replace with - or _) instead of producing %20 in the path.

Yeah, i know by default the browser will encode the space " " to %20 as seen in the first image

Here is the codebase.

Question / Suggestion:
Would this be considered a bug or a feature request?
It might be useful if TanStack Router could either:

Warn or disallow spaces in folder names, or

Provide an option (e.g., via vite.config.ts) to normalize spaces automatically (e.g., convert to - or _), instead of producing %20 in the path.

Your Example Website or App

it is closed source

Steps to Reproduce the Bug or Issue

Steps to Reproduce

1. Under the folder routes/ with a space in its name (e.g. folder/).
2. Add an index.tsx inside it.
3. Start the dev server and open the route.

Result: URL becomes /%20folder.
Expected: Should warn or normalize instead of %20.

Expected behavior

Expected Behavior

Instead of producing %20 in the URL, TanStack Router should either:

• Warn or disallow spaces in folder names, or
• Normalize spaces automatically (e.g., replace with - or _).

Screenshots or Videos

No response

Platform

• Router / Start Version: v1.129.7
• OS: Mac
• Browser: Chrome and Dia
• Bundler: Vite
• Bundler Version: ^6.0.5

Additional context

No response

[schiller-manuel]

we could think of some hook that gets called by the generator, but TBH i don't think this is a common issue

[yhoungdev]

Yea, its not a common iss, but can actually be an oversight.

[nlynzaad]

@yhoungdev encoding spaces as %20 for URLs is in line with the URL standards. Not encoding the space would result in an invalid URL.

While it might be true for 99% of cases, that a leading space is by accident and an error would assist in troubleshooting, we would also not want to assume to know best for our users should they wish to have a URL with a leading space or anywhere in their URL.

As such we feel it best to keep with the current solution.