In the Next.js App Router, what does a folder wrapped in parentheses — for example app/(marketing)/about/page.tsx — do to the resulting URL, and why would you create one?
answer
- folder name never reaches the address bar
- organise files without changing URLs
- scopes a layout to a subset
- parentheses erased before route matching
- two groups, one path, build error
basics
~20 sA parenthesised folder is a route group: Next omits it from the URL, so app/(marketing)/about/page.tsx still serves /about. Groups let you organise route files and scope a layout to a subset of routes without adding a URL segment.
solid answer
~50 sA folder in parentheses is a **route group**. Next strips it out when it builds the URL, so `app/(marketing)/about/page.tsx` serves `/about`, not `/marketing/about`. There are two reasons to reach for one. The first is organisation — you can gather a whole section under `(marketing)` or `(shop)` without that name leaking into the address bar. The second, and the one interviewers care about, is layout scoping: a `layout.tsx` placed inside the group wraps only the routes in that group, so marketing pages get a marketing shell and product pages get an app shell while both stay at the top of the URL space. You can go further and give each group its own root layout rendering `<html>` and `<body>`. The rule that bites: two groups may not contain routes that resolve to the same path — the parentheses are erased before matching, so the build fails.
go deeper
Recall the one-line rule: a folder in parentheses is dropped from the URL. Be able to read a small app/ tree aloud and say which URL each page.tsx serves.
Explain why the feature exists rather than just what it does: it decouples layout nesting from URL nesting, letting you scope a layout.tsx to a subset of routes or opt one route out of a shared shell.
Show you know the failure modes — duplicate resolved paths break the build, and multiple root layouts turn cross-group navigation into a full document load that discards client state. Say when that tradeoff is worth taking.
Own the directory convention for a large app: which sections earn their own group, whether the marketing and product halves justify separate root layouts, and how you keep a team from treating groups as a security or namespacing mechanism.
## The convention In the App Router, every folder under `app/` normally contributes one segment to the URL. A folder whose name is wrapped in parentheses is the exception: it is a **route group**. It exists in the file tree and it participates in layout nesting, but it contributes nothing to the URL. ``` app/ (marketing)/ layout.tsx about/page.tsx -> /about pricing/page.tsx -> /pricing (app)/ layout.tsx dashboard/page.tsx -> /dashboard ``` The name inside the parentheses is arbitrary and never visible to a user. Teams normally name it after the section it collects. ## URL nesting and layout nesting are different things This is the mental model worth carrying out of the topic. In the App Router, one folder normally does two jobs at once — it adds a URL segment *and* it adds a level of layout nesting. A route group is the seam where those two jobs come apart: it adds a level of layout nesting with no URL segment. Everything route groups are good for follows from that one property. ## Reason one: organisation A large `app/` directory flattens badly. Grouping ten marketing routes under `(marketing)` and fifteen product routes under `(app)` makes the tree readable, and users never see the difference. This alone is a legitimate use. ## Reason two: scoping a layout A `layout.tsx` applies to every route beneath it. Without route groups, the only way to give two sets of routes different chrome is to push them under different URL prefixes — `/marketing/about` and `/app/dashboard` — which makes the URL structure a hostage of the layout structure. With a group you keep `/about` and `/dashboard` at the root of the URL space and still give each its own shell: ```tsx // app/(marketing)/layout.tsx — wraps /about and /pricing only export default function MarketingLayout({ children, }: { children: React.ReactNode }) { return ( <> <MarketingNav /> {children} </> ) } ``` The same trick works in reverse: to opt one route *out* of a shared layout, move it into its own group. ## Multiple root layouts You can delete the top-level `app/layout.tsx` and instead give each group a `layout.tsx` that renders its own `<html>` and `<body>`. Each group then has a genuine root layout. Two consequences follow. The home page must live inside one of the groups (for example `app/(marketing)/page.tsx`), because there is no longer a top-level layout to wrap a top-level page. And navigating between two different root layouts is a **full document load**, not a client-side transition — the React tree is torn down, so client state, in-memory caches and scroll position are lost. That is a reasonable price when the two halves really are separate applications (a marketing site and a signed-in product), and a bad one when they share UI. ## The rule that bites Route groups are not a namespace. Both of these resolve to `/about`: ``` app/(marketing)/about/page.tsx app/(shop)/about/page.tsx ``` The parentheses are removed before route matching, so the two are duplicates and the build fails with a conflicting-path error. Interviewers like this because it proves you understand that the group is erased rather than hidden. ## What route groups are not - They are not access control. Routes inside a group are exactly as public as any other route; the folder name simply does not appear. - They cannot remove a segment that is genuinely part of the URL — `(dashboard)/settings` serves `/settings`, so the `/dashboard` prefix is gone entirely, not hidden. - They do not change matching precedence or priority between routes. - They are not required in order to nest layouts. Ordinary nested folders already nest layouts; groups only let you nest a layout without paying a URL segment for it.
- Can two different route groups each contain an about/page.tsx?No. The group names are stripped before matching, so both resolve to `/about` and Next fails the build on the conflicting path. Route groups organise files; they do not create a namespace. If you genuinely need two `about` pages, they need two different URLs.
- How do you get more than one root layout in an App Router project, and what do you give up?Delete `app/layout.tsx` and give each route group its own `layout.tsx` rendering `<html>` and `<body>`. The home page then has to live inside one of the groups. The cost is that moving between groups is a full document load rather than a client transition, so React state, scroll position and in-memory caches are discarded.
- Does putting a route in a group change anything a user or a crawler can observe?No. The URL, the response and the rendered HTML are unaffected by the group name itself. The only observable difference comes from what you do with the group — a different layout wrapping those routes, or a separate root layout that forces a full page load when crossing between groups.
saying these in an interview costs you the question
- Says (marketing)/about serves /marketing/about
- Thinks a route group makes its routes private or protected
- Claims two groups can each own /about safely
- Believes route groups change route matching precedence
- Says nesting layouts requires a route group