Static Assets and the public Folder

Analogy categoryAnalogies

Any file placed inside the top-level public directory is served statically at the site root: public/favicon.ico becomes accessible at /favicon.ico, and public/images/logo.png becomes /images/logo.png, with no import or build step required. This makes public the right place for files that need a stable, predictable URL — favicons, robots.txt, sitemap.xml (if not generated dynamically), PDF downloads, and manifest files referenced by third-party tools or search engine crawlers that expect a fixed path.

🏏

Cricket analogy: Files in the public folder getting a stable root-level URL is like a stadium's official scoreboard having one permanent, fixed physical location every match, so broadcasters always know exactly where to point the camera without checking each time.

public Folder vs. Importing Assets into Components

Files referenced from public are not processed by the Next.js build pipeline — no hashing, no bundling, no automatic dimension inference — so a change to public/logo.png requires manually busting caches (e.g., renaming the file or adding a query string) if you need visitors to see the update immediately. By contrast, images imported directly into a component (import logo from './logo.png') are processed by the bundler, get a content-hashed filename for cache-busting automatically, and when used with next/image, have their width and height inferred — making direct imports the better default for images that live inside your component tree rather than needing a fixed external URL.

🏏

Cricket analogy: Public folder files needing manual cache-busting is like a stadium having to manually reprint a physical banner if sponsor logos change, versus a digital LED hoarding (bundled import) that updates automatically with a fresh feed.

tsx

// File structure:
// public/
//   favicon.ico            -> served at /favicon.ico
//   robots.txt             -> served at /robots.txt
//   downloads/report.pdf   -> served at /downloads/report.pdf

// app/components/DownloadLink.tsx
export default function DownloadLink() {
  return (
    <a href="/downloads/report.pdf" download>
      Download the 2026 report (PDF)
    </a>
  );
}

// Contrast: importing an image directly gets bundler processing + hashing
import logo from './brand-logo.png';
import Image from 'next/image';

export function Logo() {
  return <Image src={logo} alt="Company logo" />; // width/height auto-inferred
}

The public directory itself is not part of the URL path — public/robots.txt is served at /robots.txt, not /public/robots.txt. Next.js treats everything under public as if it were mounted directly at the domain root.

Common public Folder Use Cases

Beyond favicons and robots.txt, public is the conventional home for manifest.json (Progressive Web App metadata), Open Graph share images referenced by absolute URL in social meta tags, third-party verification files (like a Google Search Console HTML verification file that must live at an exact predetermined path), and any downloadable asset — PDFs, .zip files, or media — that users or external services need to fetch by a stable, guessable link rather than through a React component's render tree.

🏏

Cricket analogy: A fixed-path Search Console verification file is like a ground curator having to place an official pitch report at one specific, predetermined spot for the match referee's pre-toss inspection, no substitutions allowed.

Files in public are served exactly as-is with no processing, which means there's no automatic optimization, minification, or access control — anything placed there is publicly downloadable by anyone who knows or guesses the URL, so never put sensitive files (private keys, internal documents, unpublished data) inside public.

Files in the top-level public directory are served statically at the site root with no import or processing step.
public is ideal for assets needing a stable, predictable URL: favicons, robots.txt, manifest.json, verification files, downloadable PDFs.
public/robots.txt is served at /robots.txt, not /public/robots.txt — the folder name is not part of the URL.
Files in public are not bundled or content-hashed, so cache-busting after updates must be handled manually.
Images imported directly into components get bundler processing, automatic content-hashed filenames, and (with next/image) inferred dimensions.
Open Graph share images and PWA manifest files typically live in public because external tools expect a fixed, absolute path.
Never place sensitive or private files in public — everything there is publicly accessible with no built-in access control.