How to Embed a PDF in Next.js (Without SSR Errors, Performance Issues, or Poor Mobile UX)

The first time I needed to embed a PDF in a Next.js application, I assumed it would be a ten-minute task. Upload the PDF, drop it into an iframe, and move on to the next feature.

In reality, it turned into an afternoon of debugging.

The PDF displayed perfectly in Chrome but behaved differently in Safari. Mobile users complained about awkward scrolling. When I tried a more advanced PDF viewer, Next.js immediately threw a "window is not defined" error during server-side rendering. Later, a client uploaded a 40 MB product catalog that tanked page performance and made the entire experience feel sluggish.

If you've worked with PDFs in production, you've probably run into similar issues.

Embedding a PDF is easy. Embedding one that loads quickly, works across devices, doesn't break SSR, and provides a good user experience is where things become interesting.

In this guide, I'll walk through the methods I've used in real Next.js projects, explain the trade-offs of each approach, show working Next.js 14 App Router examples, and share some lessons learned after debugging more PDF-related problems than I originally expected.

By the end, you'll know when a simple iframe is enough, when React-PDF is worth the extra complexity, and when an interactive flipbook solution may make more sense for business-facing content.

A quick note before diving into code: not every PDF warrants a custom viewer. For marketing materials like brochures, catalogs, or sales decks, consider whether a specialized tool might save you time. Services like ZipFlipbook, for example, convert static PDFs into embeddable flipbooks with built-in mobile optimization, analytics, and lead capture. If that fits your use case, it's worth exploring before building something from scratch.

Why Embedding PDFs in Next.js Is More Complicated Than It Looks

At first glance, PDFs seem like a solved problem. Browsers have supported them for years, and there are dozens of libraries available for displaying them. Yet PDF-related issues continue to show up in bug trackers, support tickets, and developer forums.

The biggest reason is that a PDF isn't really web content.

Unlike HTML, which browsers understand natively and can adapt to different screen sizes, PDFs are essentially digital documents with fixed layouts. That makes them predictable for printing, but often awkward for responsive web experiences.

The Problems Most Developers Run Into

One of the first issues you'll notice is inconsistent browser rendering. Chrome, Safari, Firefox, and Edge don't always display PDFs exactly the same way. A document that looks perfect in one browser may have zoom or navigation quirks in another.

Then there are SSR issues.

Many PDF libraries assume they're running in a browser environment and immediately try to access browser APIs such as window or document. Because Next.js performs server-side rendering, these references can crash your application before the page even loads.

Large file sizes create another challenge. I've seen companies upload catalogs exceeding 100 MB and then wonder why users abandon the page before the document appears. Unlike images, PDFs are often forgotten during performance optimization efforts.

Mobile devices introduce their own set of problems. A PDF designed for desktop reading can become frustrating on a smartphone. Pinch-to-zoom interactions, tiny text, and horizontal scrolling create a poor experience that users rarely enjoy.

SEO is another commonly overlooked factor. While search engines can index PDFs, they generally prefer HTML content. A standalone PDF often has fewer ranking opportunities than a dedicated landing page built around the same information.

Finally, traditional PDF viewers offer very little insight into user behavior. You might know that someone visited the page, but not whether they actually read the document, how many pages they viewed, or where they dropped off.

Understanding these limitations makes it easier to choose the right embedding approach.

Method 1: The Simple iframe Approach

When someone asks me for the fastest way to display a PDF in a Next.js application, my answer is almost always the same: start with an iframe.

Despite being one of the oldest solutions available, it's still surprisingly effective for many use cases.

When I Use This Method

I generally choose the iframe approach when the goal is simply to display information rather than create a sophisticated document experience.

Examples include:

• Internal company documentation
• Technical manuals
• Product specification sheets
• User guides
• Quick client projects
• MVP applications

If stakeholders only need visitors to view a document, an iframe can often solve the problem with almost no development overhead.

Next.js 14 App Router Example

Place your PDF inside the public directory:

public/ └── brochure.pdf

Create a page:

// app/brochure/page.tsx export default function BrochurePage() { return ( <main className="max-w-6xl mx-auto p-6"> <h1 className="text-3xl font-bold mb-6"> Product Brochure </h1> <iframe src="/brochure.pdf" className="w-full h-[900px] border rounded-lg" /> </main> ); }

That's enough to get a working PDF viewer running in most browsers.

Pros

What I like about this method is its simplicity. There are no third-party dependencies, no worker configuration, no client-side rendering tricks, and virtually nothing that can break during deployment.

The browser handles most of the heavy lifting, which means you can spend your time working on actual product features rather than fighting library configuration.

For internal tools and documentation portals, that simplicity is often exactly what you want.

Cons

The downside is that you're giving up control.

You can't easily customize the PDF interface, track detailed engagement metrics, add search functionality, or build advanced navigation experiences. You're also relying heavily on how each browser chooses to render the document.

Eventually, many projects outgrow the iframe approach once business requirements become more sophisticated.

Performance Notes

One mistake I frequently see is setting fixed heights that work on desktop but create awkward scrolling experiences on mobile devices.

Another issue is assuming every browser supports PDF rendering equally well. While modern browsers generally do, edge cases still exist, especially in enterprise environments.

For smaller documents, these limitations may never matter. For customer-facing experiences, they often become noticeable much sooner than expected.

Method 2: Building a Custom PDF Viewer With React-PDF

When product teams start asking for custom controls, page navigation, annotations, search, or deeper integration with the application interface, React-PDF becomes a much more attractive option.

Unlike iframes, React-PDF gives you direct control over how documents are rendered and displayed.

When React-PDF Makes Sense

In my experience, React-PDF is most valuable in:

• SaaS applications
• Learning management systems
• Document management platforms
• Contract review systems
• Knowledge bases
• Educational products

These environments benefit from custom interactions that browser PDF viewers simply don't provide.