TL;DR

There is no single "PDF to website" button that produces a good result — there are four approaches, each with different trade-offs. If you want to keep the exact PDF layout, host the file and embed it in an iframe. If you want indexable, editable text, convert to HTML. If you want search and text selection inside a viewer, run PDF.js. If you just want a shareable link, publish the PDF to a static host. Pick based on whether "the website" needs to look like the PDF or read like a web page. If you are going the other direction — website to PDF — try Convert Anything to PDF to package a page as a proper document.

Option 1: host the PDF and embed with iframe

The fastest path from PDF to website is to upload the PDF somewhere public and drop it into an iframe. The file stays a PDF — every font, table, and pixel of layout is preserved because you are literally handing the browser the original binary. The browser's built-in PDF viewer does the rest.

<iframe
  src="/reports/annual-report-2026.pdf"
  width="100%"
  height="800"
  style="border: 1px solid #ccc;"
  title="Annual Report 2026">
</iframe>

This works today in Chrome, Edge, Firefox, and Safari because all four ship a PDF viewer. What you get is the native viewer chrome — page controls, download button, print button, sometimes a sidebar for thumbnails. The look varies by browser, and you cannot style it. If you need a consistent look across browsers, skip to Option 3.

A few gotchas:

  • Height needs a fixed value or explicit calc. Iframes have no intrinsic height, so height="100%" on the iframe does nothing unless the parent is a fixed-height container. Set a pixel height, or wrap it in 100vh styling.
  • Same-origin is safest. If you host the PDF on a different domain, some browsers apply extra restrictions and some corporate networks strip cross-origin iframes. Serve the PDF from the same origin as the page whenever possible.
  • Mobile Safari opens PDFs weirdly. On iOS, an iframe with a PDF often shows only the first page and a "download" prompt. This is the number-one reason people move off the iframe approach.
  • You cannot control which page opens. Standard PDF viewer URL fragments like #page=3 work in most desktop browsers but are inconsistent on mobile.

Use this for internal tools, downloads pages, quick previews, and anywhere the PDF is the whole point (a brochure, a legal filing, a slide deck). Do not use it if you want SEO — search engines index the PDF file, not the wrapping page, so the iframe adds nothing that a plain link wouldn't. See How to link to a PDF for the simpler alternative when embedding is overkill.

Option 2: convert to HTML and style

If the goal is "readable web page that came from a PDF" rather than "PDF displayed on a page," convert the PDF to HTML. You get real text, real headings, real images — content that Google indexes, screen readers can navigate, mobile users can zoom without pinching, and you can restyle to match your site.

The conversion options, roughly ordered by output quality:

  • Adobe Acrobat's Export → HTML — Best fidelity, terrible HTML. It preserves layout by using absolute positioning on every element, which reads well visually but is hostile to responsive design and semantic markup. Fine for archives, bad for anything you plan to maintain.
  • pdf2htmlEX — Open-source, generates HTML that renders identically to the source PDF using an embedded font and absolute positioning. Same trade-off as Acrobat: pixel-perfect, non-semantic.
  • pdftohtml (Poppler) — Ships with poppler-utils. Simple, plain HTML output. Loses layout, keeps content. Best when you want clean text you will restyle from scratch.
  • marker or nougat — ML-based converters that turn PDFs into Markdown with reasonable structure (headings, lists, tables). Slow, but the output is genuinely editable.
  • LLM-based conversion — Send the PDF to a model with vision, ask for clean HTML. Quality varies. Fine for one-offs, expensive at scale.

The right choice depends on what you are optimizing for. If the PDF is a magazine layout and you need it to look like the magazine, use pdf2htmlEX. If the PDF is a report and you want a normal web article, run pdftohtml -s -i file.pdf and manually clean up the output — no automated tool produces good semantic HTML from a PDF, because the PDF format does not contain semantic information in the first place. A heading looks like a heading because it is 24pt bold, not because it is tagged as <h1>.

Option 3: PDF.js viewer (search + text-selectable)

PDF.js is Mozilla's JavaScript PDF renderer — it's what powers Firefox's built-in PDF viewer, and you can drop it into any web page. Unlike the iframe approach, PDF.js gives you a consistent viewer across every browser, plus features the native viewers hide: full-text search, text selection with proper highlighting, custom toolbar controls, and hooks to jump to any page.

The default viewer at /web/viewer.html in the PDF.js distribution works out of the box:

<iframe
  src="/pdfjs/web/viewer.html?file=/reports/annual.pdf"
  width="100%"
  height="900">
</iframe>

That still uses an iframe, but the iframe now contains PDF.js's own UI instead of the browser's. Consistent controls, works on mobile, searchable text. This is what most "modern PDF embed" services (DocsPad, Issuu-lite implementations, PDFObject premium) are wrapping.

For a fully custom experience, use the library directly:

import * as pdfjsLib from 'pdfjs-dist';

const loadingTask = pdfjsLib.getDocument('/reports/annual.pdf');
const pdf = await loadingTask.promise;
const page = await pdf.getPage(1);
const viewport = page.getViewport({ scale: 1.5 });
const canvas = document.getElementById('the-canvas');
const context = canvas.getContext('2d');
canvas.height = viewport.height;
canvas.width = viewport.width;
await page.render({ canvasContext: context, viewport }).promise;

You now own every pixel — render pages into your own DOM, add annotations, gate pages behind a paywall, sync page navigation with your app's state. This is how services like DocSend, Scribd, and most legal-tech PDF viewers are built.

Trade-offs: the library is ~350 KB gzipped. First render is slower than the browser's native viewer. Text selection inside a canvas-rendered PDF requires PDF.js's text layer, which occasionally misaligns on rotated or unusual glyphs. And PDF.js does not handle every PDF perfectly — heavily interactive forms, some encrypted PDFs, and PDFs with custom fonts can fail to render or render poorly. Test with your actual files before committing.

Option 4: publish to a static site (GitHub Pages, Netlify)

If "put a PDF on the web" means "give me a URL I can share," you don't need any of the above. Publish the PDF to a static host and share the link. GitHub Pages, Netlify Drop, Cloudflare Pages, and Vercel all host static files free for hobby traffic — you drag the file in, you get a URL back.

Concrete flow for GitHub Pages:

  1. Create a new repo (public).
  2. Add your PDF: git add report.pdf && git commit -m "add" && git push.
  3. Enable Pages in Settings → Pages, source: your main branch.
  4. Your PDF is live at https://<username>.github.io/<repo>/report.pdf.

The URL is permanent, indexable by Google (which reads PDF content and shows it in results), and shareable. This is the right answer for standalone documents — a resume, a whitepaper, a slide deck, a menu — where the PDF is the deliverable and the "website" is just its address.

Netlify Drop is even simpler: drag a folder onto app.netlify.com/drop and you get a URL in about ten seconds. No account required to publish, though you'll need one to keep the site permanently. Cloudflare Pages and Vercel work similarly with a git repo.

One useful pattern: pair the direct PDF URL with a lightweight landing page. report.html holds an <h1> title, a one-paragraph summary, and a link to report.pdf. Google indexes the summary, users see a real preview before downloading, and you get a canonical URL that isn't a raw binary. This is how most whitepaper landing pages work — the PDF is the payload, the HTML is the entrance. See Download website as PDF for the mirror-image workflow (turning any web page into a PDF file to publish this way).

Mobile: responsive PDF viewers

Mobile is where every PDF-on-web strategy falls apart, so plan for it up front.

The native iframe approach fails on iOS. Mobile Safari treats an iframe containing a PDF as a special case: it shows the first page as a preview, then prompts the user to open the PDF full-screen in a separate view. If your page relies on the user scrolling through the PDF inline, iPhone users won't. Chrome on Android is closer to desktop behavior but still cramped.

PDF.js scales, but poorly by default. Text meant for A4 rendered at 100% is unreadable at 375px viewport width. The user has to pinch-zoom and pan, which is a bad experience. If you go the PDF.js route, wire up a scale that respects viewport width:

const desiredWidth = window.innerWidth - 32;
const viewport = page.getViewport({ scale: 1 });
const scale = desiredWidth / viewport.width;
const scaledViewport = page.getViewport({ scale });

Now the PDF renders at whatever scale makes the content fit. Handle window resize and orientation changes too — the recalculation should re-render.

The HTML conversion is the only truly mobile-friendly option. A PDF becomes a normal web article: text reflows, fonts scale, links tap-target correctly, screen readers read the content. If mobile experience matters more than pixel fidelity, convert to HTML and accept the layout loss. This is why almost every "read the PDF as an article" service (Instapaper, Pocket, Reader mode) does HTML conversion under the hood — PDFs simply are not responsive by design.

On mobile, always provide a download link. Users prefer opening PDFs in Files, Google Drive, or Books over fighting with an in-page viewer. Give them the choice.

SEO: making PDF content indexable

Google does index PDF content — it has since 2001 — but the ranking and presentation are meaningfully different from HTML pages. If SEO matters, know what you're getting into.

What Google indexes from a PDF:

  • The full text (up to a limit, around 10 MB or a few hundred pages)
  • The /Title metadata field, if set
  • Inbound links to the PDF URL
  • Image alt text embedded in the PDF (rare — most PDFs don't have it)

What Google can't easily use:

  • Structured data (no way to add JSON-LD to a PDF)
  • Author bylines, canonical tags, or Open Graph metadata
  • Freshness signals — PDFs get re-crawled less often than HTML pages
  • Mobile-friendliness signals — PDFs are always ranked as "not mobile-friendly"

The practical implication: a PDF will rank for the text inside it, but usually worse than an HTML page covering the same content. Google will show the PDF in results with a [PDF] tag, users hesitate to click, and even when they do, the mobile experience is worse.

If SEO is the point, convert to HTML (Option 2) and use the PDF as a secondary download. The HTML page ranks, users read it in a browser, and the PDF is available for people who want to save or print it. This is the pattern behind almost every whitepaper landing page, most annual reports, and government reports going back a decade.

If you must publish PDF-only, at minimum:

  • Set the /Title metadata field (Acrobat: File → Properties → Description).
  • Give the PDF a descriptive filename — q3-2026-earnings-report.pdf, not report_final_v2.pdf.
  • Link to it from an HTML page that describes it — Google uses the surrounding text as context.
  • Add the PDF URL to your sitemap.xml.

Frequently asked questions

How do I put a PDF on a website?

Pick one of four approaches based on what "on a website" means. To display the PDF inline with the original layout, upload the file and embed it with an <iframe src="/file.pdf">. To make the content indexable and mobile-friendly, convert the PDF to HTML and paste it into a page. For a searchable in-browser viewer that works consistently across desktop and mobile, use PDF.js. To just publish the PDF as its own URL, drop it on GitHub Pages, Netlify, or Cloudflare Pages. The iframe path is the fastest — usually under five minutes end to end.

How do I make a PDF look like a webpage?

Convert the PDF to HTML rather than embedding the binary. pdftohtml from Poppler generates plain HTML you can restyle, pdf2htmlEX preserves the exact layout using CSS positioning, and ML tools like marker produce structured Markdown. None produce great semantic HTML from a scratch PDF — a heading looks like a heading because it's bold and larger, not because it's tagged. Plan on some manual cleanup, especially for tables and lists. The alternative is to rebuild the content as a real web page and use the PDF as a printable version, which is what most magazine and report sites do.

Does Google index PDFs?

Yes. Google has indexed PDF content since 2001 and treats PDF text as searchable content that can rank in results. But PDFs rank worse than equivalent HTML pages for the same text — they lack structured data, are always flagged as "not mobile-friendly," are re-crawled less often, and users are hesitant to click [PDF]-tagged results. If ranking matters, publish the content as HTML and offer the PDF as a downloadable extra. If you must publish PDF-only, set the /Title metadata, use a descriptive filename, link to the PDF from an HTML page, and include it in your sitemap.

How do I embed a PDF on my website?

The simplest embed is a one-line iframe: <iframe src="/file.pdf" width="100%" height="800"></iframe>. Works in every modern desktop browser using their built-in PDF viewer. If you need consistent controls, mobile support, or full-text search inside the viewer, use PDF.js — either point an iframe at PDF.js's own viewer.html or use the JavaScript library to render pages into your own DOM. Avoid <embed> and <object> for PDFs; both are older and behave inconsistently across browsers. Always provide a visible download link alongside the embed for users on mobile devices.

PDF viewer library — which one?

For most projects, PDF.js (Mozilla's library, ships with Firefox) is the default choice — actively maintained, free, wide browser support, handles the majority of PDFs correctly. If you need commercial support, professional annotation tools, or enterprise PDF features (redaction, form filling, digital signatures), the paid options are PSPDFKit (now Nutrient), Apryse WebViewer (formerly PDFTron), and Foxit WebPDF Viewer. All three are expensive but battle-tested in legal, medical, and financial software. For lightweight embeds without a full viewer, PDFObject and PDFEmbed are thin wrappers around the iframe approach.

Bottom line

There is no single "convert PDF to website" answer because "website" means different things — an exact-layout display, an indexable article, a searchable viewer, or just a URL. Pick the approach that matches what you actually need: iframe for speed, HTML conversion for SEO and mobile, PDF.js for consistent viewers with search, static hosting for standalone documents. All four are legitimate; picking the wrong one wastes hours rebuilding something the other option would have handled in minutes.

If you find yourself going the other direction more often — needing to turn web pages into shareable PDFs — try Convert Anything to PDF or read How to convert PDF to URL for the reverse workflow.