Encode a PDF file as Base64 — for embedding in JSON API requests, email attachments, or HTML data URIs. The PDF stays in your browser the whole time.
Encoded PDFs are common in REST API requests that need to upload a document inside a JSON body. They’re also used by signing services that return a signed PDF inside a JSON response. The encoded form is roughly 33% larger than the original — a 1 MB PDF becomes about 1.33 MB of Base64.
Embedding a PDF in a JSON request body when calling an API — many document signing, invoicing, and storage APIs accept Base64-encoded PDFs as part of a JSON payload. Also used for inline email attachments and database storage of binary documents.
Yes — 50 MB per file. Larger PDFs slow the browser significantly during encoding. For multi-gigabyte documents, use a server-side tool instead. For typical invoices, statements, and reports, 50 MB is well over the practical maximum.
No. Base64 is a lossless encoding. The decoded bytes are byte-for-byte identical to the original PDF, including all metadata, signatures, and embedded fonts.
Most modern APIs use JSON for request and response bodies, but JSON cannot contain raw binary. When a service accepts a PDF upload, there are two patterns: multipart form upload (the file is sent as a separate part of an HTTP request, alongside JSON metadata) or Base64-embedded in JSON (the file becomes a string field inside the JSON body). The second pattern is much easier to integrate with — a client can use a normal JSON POST, no special multipart handling, no boundary strings to manage. Most cloud functions, serverless platforms, and HTTP-only environments prefer it.
Examples of services that accept Base64-encoded PDFs in JSON: document signing APIs (DocuSign, HelloSign), OCR services (AWS Textract, Google Document AI), e-invoicing platforms (Stripe, Square), compliance archives (legal hold systems, HIPAA-compliant storage).
The typical end-to-end flow looks like this. The user selects a PDF in your application. Your frontend reads the file with the FileReader API, encodes it as Base64, and constructs a JSON request body like { "document": "JVBERi0xLjcK...", "filename": "invoice.pdf", "metadata": {...} }. The frontend posts that JSON to your backend or directly to the third-party API. The receiving service decodes the Base64 back to bytes, processes the PDF (signing, OCR, storage, conversion), and returns either a result document (also as Base64) or a status/URL reference.
Our tool handles the encoding half of this flow — you drop a PDF, and you get a ready-to-paste Base64 string. For large PDFs, the result can be megabytes of text; the tool chunks the encoding to keep the browser responsive.
The 50 MB file size limit on this tool is a practical browser ceiling, not a technical one. JavaScript can encode larger files, but the browser tab can become unresponsive during the operation, and very large data URIs can crash the rendering engine. For documents up to 50 MB, the encoding completes in a few seconds. For larger documents — typical of scanned multi-hundred-page records — use a server-side tool (Node.js, Python, Go) where memory and CPU constraints are more forgiving.
Remember that Base64 inflates the file by 33%. A 10 MB PDF becomes 13.3 MB of Base64 text. If your API has a request size limit (common: 10 MB or 25 MB), keep this multiplier in mind when sizing your originals. Some APIs explicitly state limits in terms of the Base64-encoded size; others state the limit in terms of the original binary size — read the documentation carefully.
A correct Base64 encoding of a PDF will always start with the four-character prefix JVBERi0 (which decodes to %PDF-). If your output starts with anything else, either the encoding process did not run cleanly or the input file was not actually a PDF. To verify a roundtrip, take the Base64 output of this tool and paste it into our Base64 to PDF decoder — if the original PDF renders correctly, the encoding is intact.
If your downstream API rejects your encoded PDF, common causes are: extra whitespace or line breaks in the Base64 (some APIs require unwrapped output — use the standard variant, not MIME), data URI prefix included accidentally (the API wants only the Base64, not the data:application/pdf;base64, prefix), or URL-safe encoding where standard was expected. Match exactly what the API documentation specifies.