Native support for @ prefix in dynamic routes (social platform URL pattern)

[swifzui]

Goals

• Enable /@username URL patterns without middleware or rewrites
• Support static optimization and ISR for user profile routes with @ prefix
• Align Next.js routing with common social platform URL conventions (YouTube, TikTok, Instagram, X/Twitter)
• Reduce unnecessary performance overhead for a widely-used URL pattern

Non-Goals

• Changing or removing Parallel Routes functionality (the @ reserved character for slots)
• Breaking existing applications that use Parallel Routes
• Supporting every possible special character in routes (only focused on @ due to its prevalence)
• Creating a complex escape system for all reserved characters

Background

Why this feature is needed

The /@username URL pattern is an established convention across major social platforms:

• YouTube: youtube.com/@channelname
• TikTok: tiktok.com/@username
• Threads: threads.net/@username

Developers building social platforms, creator platforms, or user profile systems naturally want to follow this convention. However, Next.js reserves @ for Parallel Routes, making this impossible without workarounds.

Current alternatives (and their drawbacks)

Alternative 1: Middleware rewrites

// middleware.ts
export function middleware(request: NextRequest) {
  const userMatch = pathname.match(/^\/@([^\/]+)/)
  if (userMatch) {
    url.pathname = `/user/${userMatch[1]}`
    return NextResponse.rewrite(url)
  }
}

❌ Adds edge function execution overhead on every request
❌ Prevents optimal static generation

Alternative 2: next.config.js rewrites

// next.config.js
async rewrites() {
  return [
    { source: '/@:username', destination: '/user/:username' },
    { source: '/@:username/:videoId', destination: '/user/:username/:videoId' }
  ]
}

✅ Better performance than middleware
❌ Still requires mental mapping between URL and file structure
❌ Complicates routing logic
❌ Requires maintenance of parallel route definitions

Alternative 3: Use /user/:username URLs
❌ Doesn't follow industry-standard URL patterns
❌ Less intuitive for users
❌ Breaks convention established by major platforms

Prior art

• Remix: Supports $ for dynamic segments but also has reserved characters
• SvelteKit: Uses [param] syntax without reserved prefix characters
• Nuxt: Similar file-based routing, no @ conflicts

The difference is that @ specifically has become a de facto standard for user profiles across the web, making this limitation more impactful than other reserved characters.

Proposal

Option A: Escape syntax in folder names (recommended)

Allow developers to escape the @ character using a prefix or wrapper:

app/
  (at)[username]/          // () group notation + "at" literal
    page.tsx               // Accessible at /@username
    [videoId]/
      page.tsx             // Accessible at /@username/video123

or

app/
  \@[username]/            // Backslash escape
    page.tsx

Option B: New route.config.ts file

app/
  @[username]/
    route.config.ts
    page.tsx

// route.config.ts
export const config = {
  literalPrefix: true  // Treat @ as literal, not parallel route
}

Option C: Double character for parallel routes

Change the parallel route syntax to require @@:

app/
  @@slot/              // Parallel route
  @[username]/         // Literal @ route

⚠️ This would be a breaking change

Recommendation

Option A (escape syntax) seems most aligned with Next.js conventions:

• Uses existing route group () concept
• No breaking changes
• Clear intent in file structure
• Backward compatible

Example implementation

app/
  (at)[username]/
    page.tsx
    [videoId]/
      page.tsx

// app/(at)[username]/page.tsx
export default function ProfilePage({ 
  params 
}: { 
  params: { username: string } 
}) {
  return <h1>@{params.username}</h1>
}

export async function generateStaticParams() {
  // Full static generation support
  return [{ username: 'popular-creator' }]
}

Accessible at: domain.com/@username

Am I interested in contributing?

Yes! If the team is open to this approach, I'm happy to:

• Work on the implementation
• Add tests
• Update documentation
• Create examples showing the pattern

Would love to hear feedback on which option (A, B, or C) would be most aligned with Next.js's architecture and future direction.