Using `fetch` in Next.js: Extended Options Explained

The Next.js fetch options extend the browser's built-in fetch function with server-side behavior you cannot express with the standard Web API. These options live in two places: the cache option, which decides whether a response is stored, and the next object, which carries revalidation and tag settings.

App.tsx

// app/posts/page.tsx
type Post = { id: number; title: string };
 
export default async function PostsPage() {
  const res = await fetch("https://api.example.com/posts", {
    cache: "force-cache",
    next: { revalidate: 60 },
  });
  const posts: Post[] = await res.json();
  return <p>{posts.length} posts</p>;
}

This request is cached and revalidated every 60 seconds. Visitors inside that window get the stored response, and the next request after it expires fetches fresh data in the background.

The cache option

The cache option controls whether and how a server-side fetch response is stored. Its default is auto no cache, which fetches once during build for prerendered routes and on every request when request-time APIs are used.

force-cache is the explicit opt-in that makes a request cacheable. It also works for POST requests and requests with cookie or authorization headers, which the default never caches.

Revalidation with next.revalidate

The next.revalidate option sets the cache lifetime in seconds. Use 0 to never cache and false to cache indefinitely.

App.tsx

// app/posts/page.tsx
export default async function PostsPage() {
  const res = await fetch("https://api.example.com/posts", {
    next: { revalidate: 3600 },
  });
  const posts = await res.json();
  return <p>{posts.length} posts</p>;
}

The response is reused for up to an hour. Conflicting options, like combining revalidate with no-store, are ignored and trigger a development warning.

Tags with next.tags

Tags let you invalidate a cached response on demand without waiting for the timer. Tag the request, then drop the tag after a mutation.

typescript

// app/lib/posts.ts
export async function getPosts() {
  const res = await fetch("https://api.example.com/posts", {
    next: { tags: ["posts"] },
  });
  return res.json();
}

After a write, call revalidateTag with the same tag to invalidate every response that carries it. Since Next.js 16 it takes a second argument, and the recommended value is the max profile, which serves the stale response while a fresh one loads in the background. The choice between this and updateTag is covered in revalidateTag vs updateTag.

typescript

// app/posts/actions.ts
"use server";
 
import { revalidateTag } from "next/cache";
import { requireEditor } from "@/lib/auth";
 
export async function refreshPosts() {
  await requireEditor();
  revalidateTag("posts", "max");
}

The next visit to a page that uses the tag gets fresh data, and every page carrying that tag updates together. The auth check is there because an exported Server Action is a public endpoint that anyone can call, so it needs the same session check a route handler would.

The single-argument form, revalidateTag("posts"), still runs but is deprecated, so update existing calls when you touch them.

Deduplication is separate

Caching stores a response across requests, and you opt into it with the options above. Deduplication is different: identical GET requests are memoized automatically inside a single render pass, and that memo never survives past the render. So deduplication needs no options, while persistence always does.

A good rule of thumb is to tag anything that changes when a user mutates data, and to leave a revalidate timer on content that only needs periodic freshness.