How to encode a PDF to Base64

Drop or choose your PDF — drag the file onto the drop zone or click to open the file picker. Only genuine PDF files are accepted; the tool checks the %PDF magic header, not just the filename.
Select an output format using the format tabs. Choose based on where you intend to use the encoded output — API payload, HTML page, download link, or JSON body. See the format guide below.
Copy the output with the copy button. The encoded string updates immediately when you switch formats — no re-encoding needed.
For large PDFs (over ~10MB after encoding), be aware that the output string will be ~33% larger than the original file. Check your target system's payload or storage limits before sending.

Output format guide — which one to use

Six output formats are available. Choosing the wrong one is the most common source of confusion — a data URI that works perfectly in an HTML attribute will be rejected by most APIs.

Plain Base64Raw Base64 string

Use when: Sending a PDF payload to an API, storing in a database TEXT/BLOB column, or passing to a language's Base64 decode function.

JVBERi0xLjQKJcfs...

Data URIdata:application/pdf;base64,…

Use when: Setting the src attribute in JavaScript, embedding in a CSS background, or passing directly to window.open() to display the PDF in a new tab.

data:application/pdf;base64,JVBERi0x…

HTML embed<embed src="data:…" />

Use when: Inline PDF viewer in an HTML page. Renders using the browser's built-in PDF plugin. Works in Chrome and Firefox; Safari on iOS does not support PDF embed.

<embed src="data:application/pdf;base64,…" type="application/pdf" width="100%" height="600px" />

HTML hyperlink<a href="data:…" download="…">

Use when: Triggering a browser download from a button or link — no server required. The download attribute sets the suggested filename. Works across all modern browsers.

<a href="data:application/pdf;base64,…" download="report.pdf">Download PDF</a>

HTML object<object data="data:…"> with fallback

Use when: Embedded PDF viewer with a fallback message for browsers that cannot display it. More standards-compliant than embed; preferred when accessibility and graceful degradation matter.

<object data="data:application/pdf;base64,…" type="application/pdf">PDF cannot be displayed.</object>

JSON{ "base64": "…", "dataUrl": "…", … }

Use when: REST API payloads, webhooks, or structured storage. The JSON output includes fileName, mimeType, encoding, raw base64, and the full data URI — ready to include in a request body.

{ "fileName": "doc.pdf", "mimeType": "application/pdf", "encoding": "base64", "base64": "JVBERi0x…" }

Why PDFs need Base64 encoding

PDF is a binary format. It contains raw bytes — many of which are control characters, null bytes, and values outside the printable ASCII range. When you try to embed binary data directly inside a text-based format (JSON, XML, HTML, or email), those binary bytes corrupt the structure.

A null byte inside a JSON string terminates the string early in some parsers. A byte with value 0x3C (<) inside XML is interpreted as a tag opening. An 0x0D byte (carriage return) in a MIME email body signals end-of-line. Binary data in text contexts causes silent data corruption.

Base64 solves this by converting every group of 3 binary bytes into 4 printable ASCII characters drawn from a safe 64-character alphabet: A–Z, a–z, 0–9, +, and /. The output contains no control characters, no null bytes, and no characters with special meaning in JSON, XML, HTML, or email — making any binary file safe to embed in any text protocol.

The 33% size trade-off

Base64 encoding always increases file size by exactly one-third. Every 3 bytes of binary data become 4 ASCII characters — a 33.3% overhead. This is a fundamental property of the encoding, not a tool limitation.

Original PDF size	Encoded size	Practical implication
100 KB	~133 KB	Safe for data URIs, inline HTML, most APIs
1 MB	~1.33 MB	Fine for most APIs; slightly slow as inline data URI
5 MB	~6.7 MB	Approaching email attachment limits; check API limits
10 MB	~13.3 MB	Exceeds many API payload limits — use multipart upload instead
25 MB	~33.3 MB	Exceeds most email provider limits — use a file hosting URL

For PDFs over 5MB, consider whether Base64 is the right approach. Multipart/form-data uploads, presigned S3 URLs, and file hosting services handle large binaries more efficiently than Base64-in-JSON.

Real-world use cases

Sending a PDF through a REST API

Most REST APIs exchange JSON, which cannot contain raw binary data. Encode the PDF to plain Base64 and include it as a JSON string field. On the receiving end, decode the Base64 string back to binary and save it as a .pdf file. This pattern is used by email APIs (SendGrid, Mailgun), document generation services, and storage APIs (AWS S3 presigned uploads via form data).

Embedding a PDF viewer in a webpage

Use the HTML embed or HTML object output format and paste it directly into your HTML. The browser renders its built-in PDF viewer inline — no external hosting required, no CORS issues. Best for small PDFs (under 2MB encoded) since large data URIs can slow page load.

Creating a no-server download button

Use the HTML hyperlink output and paste it into your page. Clicking the link downloads the PDF directly from the browser — no server, no file hosting. Useful for static sites and single-page apps that generate or receive PDFs programmatically.

Storing PDFs in a database without a file server

Some architectures store documents directly in a database TEXT or BLOB column alongside their metadata, avoiding the need for a separate file storage service. Encode to plain Base64, store the string, and decode on retrieval. Be mindful of the 33% size overhead — a 5MB PDF becomes roughly 6.7MB encoded.

Including PDFs in HTML email

HTML email clients support Base64-encoded attachments inline via the MIME multipart format. Encode the PDF to plain Base64, wrap it in a MIME part with Content-Type: application/pdf and Content-Transfer-Encoding: base64, and include it in the multipart message. Most email APIs accept this format directly.

Common mistakes

Most errors with PDF Base64 encoding come from using the wrong output format or ignoring the size overhead.

Using a data URI in an API request bodymost common

Wrong

// Sending the full data URI — wasteful and often rejected
{
  "pdf": "data:application/pdf;base64,JVBERi0x…"
}

Correct

// Send plain Base64 only — decode the prefix first
{
  "pdf": "JVBERi0x…"
}

The data URI prefix (data:application/pdf;base64,) is for browser consumption — HTML src attributes and JavaScript. Most APIs expect raw Base64 without the prefix and will either reject the request or misparse the field if you include it. Use the plain Base64 output format for API payloads.

Ignoring the 33% size overhead

Wrong

// 10MB PDF file — assume API accepts up to 10MB JSON bodies
fetch("/api/upload", { body: JSON.stringify({ pdf: base64String }) })

Correct

// 10MB PDF encodes to ~13.3MB — exceeds most API payload limits
// Use multipart/form-data or a presigned URL for large files instead

Base64 encoding inflates file size by exactly 33% (every 3 bytes of binary become 4 ASCII characters). A 10MB PDF becomes ~13.3MB encoded. Most APIs, email servers, and HTTP proxies have payload size limits — commonly 10MB for APIs, 10–25MB for email. For large PDFs, upload directly via multipart/form-data or a presigned storage URL instead.

Using embed on Safari iOS without a fallback

Wrong

<!-- Breaks silently on Safari iOS — no PDF visible -->
<embed src="data:application/pdf;base64,…" type="application/pdf" />

Correct

<!-- object tag with fallback link -->
<object data="data:application/pdf;base64,…" type="application/pdf">
  <a href="data:application/pdf;base64,…" download="doc.pdf">Download PDF</a>
</object>

Safari on iOS does not support inline PDF rendering via <embed> or <object> with data URIs. Use the HTML object format which includes a fallback content block — users on iOS will see the fallback link and can still download the PDF. Chrome, Firefox, and desktop Safari render inline without issues.

Uploading a non-PDF file renamed to .pdf

Wrong

// A Word .docx file renamed to report.pdf
// The tool will reject it with "not a valid PDF" error

Correct

// Upload the actual PDF — the tool checks the %PDF magic header
// Convert your document to PDF first using your OS print dialog

PDF files always begin with the bytes %PDF (hex: 25 50 44 46). This tool verifies the file's magic header, not just its name or extension. A file renamed to .pdf but originating from Word, Excel, or any other format will fail validation. Use your operating system's "Print → Save as PDF" to produce a genuine PDF first.

Related tools

Base64 to PDF Decoder — Reverse the workflow — paste Base64 or a data URI back into a viewable PDF file.
Base64 Encoder — Encode smaller binary payloads with the same controls when you are not starting from a PDF file.

Frequently asked questions

Is the PDF file uploaded to a server when I encode it?

No. The entire encoding process runs in your browser using the FileReader API and JavaScript. Your PDF is read from your local file system, converted to Base64 in memory, and never transmitted over the network. You can disconnect from the internet after the page loads and the tool will continue to work.

What is a PDF data URI and when should I use one?

A data URI is a URL that contains the file's content directly rather than pointing to an external location. For a PDF, it takes the form data:application/pdf;base64,<encoded-string>. Use it when you want to embed or link to a PDF without hosting the file on a server — in HTML src attributes, download links, or JavaScript. Avoid data URIs for large PDFs (over 2MB) as they can slow page parsing and are not cached by browsers the same way external URLs are.

Why does Base64 increase the file size by 33%?

Base64 encodes every 3 bytes of binary data into 4 ASCII characters. Since ASCII uses only 6 of the 8 available bits per character (64 characters = 2⁶), each 3-byte group (24 bits) maps to four 6-bit groups represented as 4 characters. This means 3 bytes in → 4 bytes out, a 33.3% increase. Padding characters (=) are added to make the output length a multiple of 4.

Which HTML output format should I use — embed or object?

What is the maximum PDF size I can encode?

There is no hard limit imposed by this tool — it is constrained by your browser's available memory. In practice, browsers handle files up to several hundred megabytes comfortably, though very large PDFs will produce extremely long Base64 strings. Note that a 10MB PDF encodes to ~13.3MB of text. If you plan to use the output in an API request or email, check the payload size limits of your target service before encoding large files.

Can I use the JSON output format directly in a fetch() request?

Yes. The JSON output includes the fileName, mimeType, encoding, raw base64 string, and full data URI. You can use JSON.parse() on the output, extract the base64 field, and include it in a fetch POST body as part of your request JSON. Most document and email APIs expect the raw base64 field, not the full data URI — use the base64 field, not dataUrl.

How do I verify the Base64 output is a valid PDF?

A valid Base64-encoded PDF always starts with JVBERi0 — this is the Base64 encoding of the bytes %PDF (the PDF magic header required by ISO 32000, the PDF specification). If your encoded output starts with these characters, the source file is a genuine PDF. If not, the file may have been corrupted during encoding or was not a PDF to begin with.

What MIME type should I declare for a PDF?

The correct MIME type for PDF files is application/pdf, standardised by IANA. This is what this tool uses in all output formats — data URIs, HTML embed, and the JSON output. Some older systems use application/x-pdf or application/octet-stream, but application/pdf is the correct, universally supported value. Using the wrong MIME type can prevent browsers from rendering the PDF inline and may cause download dialogs to show incorrect file type information.

PDF to Base64 Encoder