Can a PDF actually be responsive like a website?

Not in the same way. HTML is reflowable by design — text reflows to fit the container, images resize fluidly, CSS media queries change layout at breakpoints. PDF is fixed-layout by design — every glyph is positioned at a specific coordinate on a specific page size. You can approximate mobile-friendly through three mechanisms: a smaller page size that matches phone aspect ratios (5"×8" is close to phone screens), a larger body font (14–16pt) so text remains readable at native zoom, and tagged PDFs with reading order metadata that lets reflow-capable readers (Acrobat Reader iOS, PDF Expert) reflow text into single column on phones. None of these turns a PDF into HTML, but together they make PDFs that are genuinely readable on mobile rather than zoom-and-pan ordeals.

What page size produces the best mobile PDF reading experience?

Two good options. First, 5"×8" (mass-market paperback) at 14pt body text — close to phone aspect ratio, comfortable text size at native zoom, well-tested on Kindle and similar readers. Second, "screen-sized PDF" at 600×1024 pixels (or 1080×1920 for full-resolution phones) with 16pt body text — fills the phone screen edge-to-edge in landscape, no zoom required. The screen-sized option requires content to be designed for that aspect ratio (no wide tables, no wide images), but produces a notably better mobile experience. The cost: the same file is awkward to print, so consider whether the document is print-and-mobile or mobile-only.

What is a "tagged PDF" and how does it help on mobile?

A tagged PDF includes structural metadata describing reading order, heading levels, paragraph boundaries, lists, tables, and figures — essentially the same semantic structure that HTML carries. Reflow-capable readers (Acrobat Reader on iOS / Android, PDF Expert, recent Apple Preview) can use this metadata to re-flow the visible text into a single column at the user's preferred font size, ignoring the original page boundaries. The result is a reflow view that looks more like a web page than a PDF. Word and InDesign produce tagged PDFs by default when "preserve structure" or "create tagged PDF" is enabled in export options. Older PDFs and most scanned PDFs are not tagged; reflow on those produces inconsistent results.

My PDF is for a public website. Should I just convert it to HTML instead?

Yes, in most cases. HTML pages are genuinely responsive, mobile-friendly by default, indexable by Google, sharable on social media, and faster to load than PDFs. PDF is the right choice when (a) the document has a strong print-distribution use case, (b) it has formal authority that benefits from a frozen citable version (legal filings, research papers, regulatory documents), or (c) the content is fundamentally layout-sensitive (architectural drawings, sheet music). For everything else — blog posts, product documentation, marketing collateral, knowledge-base articles — HTML is the better choice. Many publishers do both: HTML for the canonical web version, downloadable PDF for the print/archive use case.

How do I shrink a PDF for mobile delivery without losing readability?

Compress images aggressively, keep text. ScoutMyTool Compress PDF "aggressive" mode downsamples embedded images to 150 DPI (sufficient for screen viewing including retina), recompresses JPEGs at quality 70 (still visually clean), and removes embedded thumbnails and unused fonts. Text remains crisp because text in PDF is rendered from glyph outlines, not from rasterised images, so compression does not affect it. A typical "born-digital" document drops from 10 MB to 1–2 MB; a scanned document drops from 30 MB to 4–8 MB. For very tight bandwidth requirements (rural cellular, older 3G), aim for under 1 MB — accept some visible image compression artefacts as the trade-off.

How do I test a PDF on mobile before publishing it?

Three tests in order. First, open on your own phone in the default PDF viewer (Files app on iOS, Drive viewer on Android) — does it open quickly, is the first page readable without zoom? Second, try the reflow mode in Adobe Reader iOS or Android — does the text re-flow cleanly into single column? Third, share to a few people on different phone models (Android, older iPhone, recent iPhone) and ask them to confirm. The cross-device test catches font and rendering issues you would not notice on your own hardware. For high-stakes publications, also test on the older readers your audience may use (embedded PDF viewers in third-party apps, older corporate IT-locked devices).

Can I add hyperlinks in a PDF so the mobile experience feels more like a webpage?

Yes — and you should, for any multi-section document destined for mobile reading. Add a hyperlinked table of contents at the front of the PDF: each entry is a click-jump to the section. Use Word's "Insert → Cross-reference" or InDesign's hyperlink panel to create internal links. For external references, add real URLs as PDF link annotations (Word's "Insert → Link" produces these on export). On phone, the entire navigation feels webpage-like: tap a TOC entry to jump, tap a footnote superscript to jump to the note, tap a citation to open the source URL. Without internal links, the PDF defaults to "scroll through 50 pages to find what you need", which is the mobile-reading experience people complain about.

7 min read

How to make a PDF mobile-friendly — responsive layouts

By ScoutMyTool Editorial Team · Last updated: 2026-05-20

About 60% of PDF opens now happen on a phone, depending on the audience — and the default "exported from Word at Letter size" PDF renders at unreadable size on every phone. PDFs are fixed-layout by design, so they will never be as fluid as HTML, but with the right page size, body font, and structural tagging they can be genuinely readable on mobile rather than the pinch-and-pan ordeal most people expect. This article maps the common mobile-PDF problems, what causes each, and the export and post-processing steps that produce a phone-friendly file.

Common mobile problems and their fixes

Problem	Cause	Fix
Text too small to read without zooming	Page exported at 12pt for Letter; renders as ~4pt on phone screen	Re-export at larger body size (14–16pt) and smaller page size (5"×8" or A5)
Multi-column layout forces side-scrolling	Two- or three-column layouts intended for print do not collapse on mobile	Re-export as single-column; or use reflow-aware tagged PDF
Pinch-zoom breaks position; text reflows unpredictably	PDF is fixed-layout — pinch-zoom changes magnification, not text-flow	Use PDF readers with reflow mode (Acrobat Reader iOS, PDF Expert) on the same file
Embedded images blur on retina screens	Images downsampled to 96 DPI for screen; retina expects 200+	Re-export images at 200 DPI; accept larger file size
Tables truncate at screen edge	Print-sized table widths exceed phone width	Restructure tables to fewer columns; or use horizontal-scroll-aware PDF readers
Footnotes and references hard to follow on phone	PDF default footnotes require scroll to page bottom; awkward on phone	Use hyperlinked footnotes (clickable superscript jumps to note, click-back returns)
Large file size kills mobile data	PDF was not compressed for mobile-friendly delivery	Compress at 150 DPI image downsampling; target under 2 MB for mobile delivery

Step by step — convert a Word document to a mobile-friendly PDF

Set page size to 5"×8" (or A5). Word: Layout → Size → More Paper Sizes → Custom (5×8). Phones have aspect ratios near 9:16; 5×8 (1:1.6) is close enough to feel natural.
Increase body font to 14pt. Apply to all paragraph styles, not just one paragraph at a time. 14pt at 5×8 reads comfortably on most phones at native zoom.
Use single-column layout. No multi-column body text. For tables, keep under 4 columns or restructure as nested lists.
Add a hyperlinked table of contents. Word: References → Table of Contents. The TOC becomes clickable in the exported PDF, replacing scroll with tap-jump on mobile.
Export as tagged PDF, then compress. Word: Save As → PDF → Options → "Document structure tags for accessibility" enabled. Then compress to under 2 MB for mobile delivery.

PDF accessibility: tagged PDFs improve both mobile and screen-reader experience.
Compress PDF: shrink files for mobile data networks.
Fix PDF margins: adjust margins for mobile-friendly page proportions.
PDF table of contents: hyperlinked navigation for mobile.
PDF best practices for SEO: mobile-friendliness is also a ranking signal.
Make a PDF look professional: typographic rules that compound with mobile-friendly layout.
All ScoutMyTool PDF tools: post-export tools.

FAQ

Can a PDF actually be responsive like a website?: Not in the same way. HTML is reflowable by design — text reflows to fit the container, images resize fluidly, CSS media queries change layout at breakpoints. PDF is fixed-layout by design — every glyph is positioned at a specific coordinate on a specific page size. You can approximate mobile-friendly through three mechanisms: a smaller page size that matches phone aspect ratios (5"×8" is close to phone screens), a larger body font (14–16pt) so text remains readable at native zoom, and tagged PDFs with reading order metadata that lets reflow-capable readers (Acrobat Reader iOS, PDF Expert) reflow text into single column on phones. None of these turns a PDF into HTML, but together they make PDFs that are genuinely readable on mobile rather than zoom-and-pan ordeals.
What page size produces the best mobile PDF reading experience?: Two good options. First, 5"×8" (mass-market paperback) at 14pt body text — close to phone aspect ratio, comfortable text size at native zoom, well-tested on Kindle and similar readers. Second, "screen-sized PDF" at 600×1024 pixels (or 1080×1920 for full-resolution phones) with 16pt body text — fills the phone screen edge-to-edge in landscape, no zoom required. The screen-sized option requires content to be designed for that aspect ratio (no wide tables, no wide images), but produces a notably better mobile experience. The cost: the same file is awkward to print, so consider whether the document is print-and-mobile or mobile-only.
What is a "tagged PDF" and how does it help on mobile?: A tagged PDF includes structural metadata describing reading order, heading levels, paragraph boundaries, lists, tables, and figures — essentially the same semantic structure that HTML carries. Reflow-capable readers (Acrobat Reader on iOS / Android, PDF Expert, recent Apple Preview) can use this metadata to re-flow the visible text into a single column at the user's preferred font size, ignoring the original page boundaries. The result is a reflow view that looks more like a web page than a PDF. Word and InDesign produce tagged PDFs by default when "preserve structure" or "create tagged PDF" is enabled in export options. Older PDFs and most scanned PDFs are not tagged; reflow on those produces inconsistent results.
My PDF is for a public website. Should I just convert it to HTML instead?: Yes, in most cases. HTML pages are genuinely responsive, mobile-friendly by default, indexable by Google, sharable on social media, and faster to load than PDFs. PDF is the right choice when (a) the document has a strong print-distribution use case, (b) it has formal authority that benefits from a frozen citable version (legal filings, research papers, regulatory documents), or (c) the content is fundamentally layout-sensitive (architectural drawings, sheet music). For everything else — blog posts, product documentation, marketing collateral, knowledge-base articles — HTML is the better choice. Many publishers do both: HTML for the canonical web version, downloadable PDF for the print/archive use case.
How do I shrink a PDF for mobile delivery without losing readability?: Compress images aggressively, keep text. ScoutMyTool Compress PDF "aggressive" mode downsamples embedded images to 150 DPI (sufficient for screen viewing including retina), recompresses JPEGs at quality 70 (still visually clean), and removes embedded thumbnails and unused fonts. Text remains crisp because text in PDF is rendered from glyph outlines, not from rasterised images, so compression does not affect it. A typical "born-digital" document drops from 10 MB to 1–2 MB; a scanned document drops from 30 MB to 4–8 MB. For very tight bandwidth requirements (rural cellular, older 3G), aim for under 1 MB — accept some visible image compression artefacts as the trade-off.
How do I test a PDF on mobile before publishing it?: Three tests in order. First, open on your own phone in the default PDF viewer (Files app on iOS, Drive viewer on Android) — does it open quickly, is the first page readable without zoom? Second, try the reflow mode in Adobe Reader iOS or Android — does the text re-flow cleanly into single column? Third, share to a few people on different phone models (Android, older iPhone, recent iPhone) and ask them to confirm. The cross-device test catches font and rendering issues you would not notice on your own hardware. For high-stakes publications, also test on the older readers your audience may use (embedded PDF viewers in third-party apps, older corporate IT-locked devices).
Can I add hyperlinks in a PDF so the mobile experience feels more like a webpage?: Yes — and you should, for any multi-section document destined for mobile reading. Add a hyperlinked table of contents at the front of the PDF: each entry is a click-jump to the section. Use Word's "Insert → Cross-reference" or InDesign's hyperlink panel to create internal links. For external references, add real URLs as PDF link annotations (Word's "Insert → Link" produces these on export). On phone, the entire navigation feels webpage-like: tap a TOC entry to jump, tap a footnote superscript to jump to the note, tap a citation to open the source URL. Without internal links, the PDF defaults to "scroll through 50 pages to find what you need", which is the mobile-reading experience people complain about.

Citations

ISO 32000-1:2008 — "Document management — Portable document format" — §14.8 (Tagged PDF) defining the structure metadata used for reflow.
WCAG 2.1 — Web Content Accessibility Guidelines, including PDF reflow requirements (criterion 1.4.10).
Adobe — "Create accessible PDFs" — guidance on tagged-PDF export.
Google Search Central — "Mobile-first indexing" — applies to PDFs as well as HTML.

Optimise post-export for mobile

ScoutMyTool's compress and edit tools run client-side. Shrink for cellular delivery, fix margins, add a TOC — without uploading the file.

Open the PDF toolkit →