This is a genuinely surprising failure mode the first time you hit it, since the natural assumption is that an unmatched parallel route slot would just render nothing, not take down a page that has nothing to do with the slot in question.
The Setup From an Earlier Post, Extended
Building on the intercepting route modal pattern from an earlier post, the @modal slot renders the modal when a specific route is intercepted. But a parallel route slot needs to render something for every URL within its scope, not just the one specific route it was built for.
app/
├── @modal/
│ ├── (.)photo/
│ │ └── [id]/
│ │ └── page.tsx // renders when a photo route is intercepted
│ └── (missing: default.tsx)
├── photo/
│ └── [id]/
│ └── page.tsx
├── settings/
│ └── page.tsx // a completely unrelated route
├── layout.tsx
└── page.tsx
Why Visiting an Unrelated Page Can Break Entirely
The @modal slot is defined at the root layout level here, which means it's part of every route rendered under that layout, not just the photo routes it was actually built for. Next.js needs to know what @modal should render for every single route within its scope, including /settings, which has nothing to do with photos or modals at all. If there's no page.tsx inside @modal matching /settings, and critically, no default.tsx file to serve as a fallback for exactly this situation, Next.js has no content to render for that slot on that route, and without a fallback, it treats this as a genuine 404 for the entire page, not just an empty modal slot.
Why This Specific Failure Mode Is So Confusing
The intercepting modal pattern itself works perfectly, clicking a photo from the grid correctly shows the modal, refreshing correctly shows the full page, exactly the behavior covered in the earlier post. The /settings page, something that looks completely unrelated to any of that photo and modal logic, is what actually breaks, with a full 404, and nothing about that page's own code gives any indication why. The actual cause lives entirely in the parallel route configuration at the layout level, several files away from the page that's actually failing, which makes this a genuinely disorienting bug to trace the first time.
The Fix: A default.tsx for Every Parallel Slot
// app/@modal/default.tsx
export default function Default() {
return null; // this slot simply renders nothing when there's no active modal
}
default.tsx tells Next.js exactly what to render for this slot whenever the current route doesn't match anything more specific within it. Returning null here is completely correct and intentional, for any route that isn't specifically showing a modal, @modal should render nothing, and default.tsx is what makes that an explicit, defined behavior instead of an unhandled gap that produces a full 404.
Why This Is Easy to Miss When First Setting Up Parallel Routes
Most tutorials and examples for intercepting routes focus entirely on the specific route being intercepted, since that's the actual feature being demonstrated, and default.tsx is easy to treat as an afterthought or skip in a quick example, since the demo itself often only ever navigates between the two or three routes that were actually set up correctly. The gap only becomes visible once someone navigates to a genuinely unrelated route that was never part of the original example, exactly the kind of route a real, full application has plenty of.
The Broader Rule
Every parallel route slot needs a default.tsx, without exception, the moment that slot exists anywhere in a layout that also renders routes the slot has no specific content for. This isn't an edge case fallback for rare situations, it's the default, expected behavior for the overwhelming majority of routes in any real application, since a slot built for one specific interaction, a modal, a sidebar variant, is inherently the exception, not the rule, across a site's full set of routes.
Checking Your Own Parallel Routes
find app -type d -name "@*"
For every parallel route slot this turns up, confirm a default.tsx exists directly inside it. If it doesn't, any route within that layout's scope that isn't specifically handled by that slot is at genuine risk of a full 404, not a minor rendering gap, the moment someone actually navigates there.
I set up a default.tsx as the very first file whenever I add a parallel route slot to any project now, client work included, for exactly this reason, it costs one trivial file and prevents a genuinely confusing, hard-to-trace production bug. If you're exploring more Next.js patterns like this, I write about them regularly at pixelanas.com/blog.
If you're using parallel routes anywhere, run the check above right now and confirm every slot has its fallback file. If one doesn't, you've got a real, ready-to-happen 404 waiting on some route you haven't tested yet. Drop what you find in the comments.
Get the templates: https://pixelanas.gumroad.com
Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751
Top comments (0)