Parallel and Intercepting Routes

Most routing you have learned so far maps one URL to one page rendered in one place. But real interfaces are often more sophisticated than that: a dashboard might show several independent regions that each have their own navigation and loading state, or a photo gallery might open an image in a modal overlay while keeping the gallery behind it, with the URL still updating so the modal is shareable and survives a refresh. Parallel routes and intercepting routes are the two advanced App Router features that make these patterns expressible in the file system rather than hacked together with client state. Parallel routes let one layout render multiple independent route slots simultaneously; intercepting routes let a navigation be caught and shown in the current layout's context — like a modal — while still corresponding to a real, refreshable URL.

These features are genuinely advanced, and it is worth being clear that you should not reach for them for ordinary pages — most of an application needs neither. They earn their place specifically when an interface has multiple independent areas that should render and load separately, or when a navigation should be presented contextually as an overlay yet remain a first-class URL. The reason they are powerful is that they solve, declaratively and with proper URL semantics, problems that developers otherwise solve with brittle client-side state: a modal built purely with useState is not shareable, breaks on refresh, and loses its place in the browser history, whereas an intercepting route gives a modal a real URL with all the navigation correctness that implies. Understanding what each feature does, the folder conventions that express them, and when each is the right tool is what lets you build these richer interfaces without sacrificing the routing model's clarity.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture a Test match where, before the openers walk out, the curator has already prepared the pitch, the umpires are positioned, and the scoreboard is live — the players just play. Plain React is like arriving at an empty ground and being told to roll the pitch, set the field, and wire up the scoreboard yourself before a single ball is bowled. Just as the prepared ground lets the batsmen focus on batting rather than groundskeeping, Next.js prepares routing, rendering, and bundling so you focus on features rather than plumbing. Just as the live scoreboard shows runs the instant a shot is played, server rendering hands the browser finished HTML the instant the page loads. And just as every Test follows the same agreed laws so any team can play anywhere, the App Router's file conventions mean any developer can read the folder structure and instantly know the routes. This reveals why Next.js wins on large teams: shared conventions remove the guesswork that custom setups create.