In Next.js, what is the difference between calling `revalidatePath('/blog')` and `revalidateTag('posts')` from `next/cache`, and what does the tag version buy you that the path version cannot?

## Both are invalidation, not regeneration The first thing to get right is that neither function renders anything. They mark cached entries invalid. The work of producing new output happens on the next request that needs the route. So "I called `revalidateTag` and my page did not change" is usually a story about no one having requested the page yet, or about looking at a copy that was never invalidated in the first place. ## `revalidatePath` — addressing by URL ```ts import { revalidatePath } from 'next/cache' revalidatePath('/blog') // that one route revalidatePath('/blog/[slug]', 'page') // every route matching that dynamic pattern revalidatePath('/dashboard', 'layout') // that segment and everything nested under it ``` The second argument declares what kind of segment the first argument names. `'page'` treats it as a leaf route; `'layout'` cascades, invalidating the nested segments beneath it as well. For a dynamic route, passing the literal bracket pattern rather than a concrete URL is how you invalidate all of its instances at once — passing `/blog/my-post` invalidates exactly that one post. Path addressing works well when the mapping from a change to affected URLs is short and obvious: an editor edits post `my-post`, so `/blog/my-post` and probably `/blog` need refreshing. It falls apart when that mapping is large, dynamic, or unknown to the caller. ## `revalidateTag` — addressing by label Tags are attached to cached data at the moment it is cached, and later invalidated by name: ```ts import { revalidateTag } from 'next/cache' revalidateTag('posts') ``` Whatever produced the cached data — a tagged data fetch, or an explicitly cached function — carries a set of string labels. `revalidateTag('posts')` invalidates every entry wearing that label, and by extension every cached route whose render depended on such an entry. This inverts responsibility, which is the real design win. With paths, the *invalidator* must know the routing structure of the site. With tags, the *reader* declares its own dependency at the point of use, and the invalidator only has to name the thing that changed. A publish webhook can say `revalidateTag('posts')` without any knowledge of whether posts appear on the home page, an index, an RSS route, a sitemap, or a sidebar in a layout — all of which quietly refresh anyway. ## Fan-out, concretely Say every fetch that reads author 42's profile is tagged `author-42`, and every fetch that lists posts is tagged `posts`. The author changes their display name. `revalidateTag('author-42')` invalidates their profile page, every article page that showed a byline, and the index cards on the home page — because each of those renders touched data wearing that tag. Doing the same with paths means computing the list of affected URLs at invalidation time, in the webhook, from data the webhook does not have. Teams that go down that road end up shipping a query whose only job is to answer "which URLs did this row appear on?", which is exactly the coupling tags remove. ## Where you may call them In current Next.js these are side-effecting APIs and belong in a Server Action or a Route Handler — a mutation path or a webhook endpoint — not in the body of a component during render. Calling them mid-render is a bug: rendering is supposed to be free of cache side effects, and Next.js treats it as an error. ## Choosing between them Use `revalidatePath` when the change maps to a small, known set of URLs and no tagging discipline exists — it needs no setup and reads obviously. Use `revalidateTag` when one change ripples across pages, when the invalidating code sits outside the app's routing knowledge (a CMS webhook is the canonical case), or when you want the dependency declared next to the data rather than in the invalidator. Most real codebases use both: tags for content entities, paths for the handful of aggregate routes that are easier to name than to label. The cost of tags is naming discipline. Tags are plain strings with no registry and no compiler help: a typo produces no error, just a page that silently never refreshes. Deriving them from a single helper (`postTag(id)`) rather than typing literals at each site is the practice that keeps them honest.