Drop a PDF and get its Base64 encoding in the two forms you actually need: a full data URI ready to embed in HTML or CSS, and the raw string for APIs and databases. The file is read locally with the browser's FileReader — it never leaves your machine.
The 33% size tax, and which output goes where
Base64 maps every 3 bytes to 4 characters, so output is always a third larger than the file: a 1,048,576-byte (1 MB) PDF becomes a 1,398,104-character string. Budget for that anywhere size limits apply — request body caps, database column widths, email attachment ceilings. The data URI form (data:application/pdf;base64,...) drops straight into an <object> or <embed> src, an <a> href, or anywhere else a URL is expected. The raw form is what JSON APIs, XML payloads, and database fields want, since they add their own framing and a data: prefix there is just corruption waiting to be debugged. One identity check worth memorizing: every PDF's raw Base64 starts with JVBER, because that is how the %PDF file header encodes. If a string claiming to be a PDF starts with anything else, it is not one.
What the tool accepts, and how big is too big
Both the picker and the drop zone take one PDF at a time, and anything that is not a PDF — checked by MIME type, with a fallback to the .pdf file extension — is refused with an error rather than encoded into garbage. After a successful read you get the filename and size in KB, then the two output boxes, each with its own copy button that confirms with a brief Copied flash; the text is also click-to-select if you prefer copying manually. There is no hard size cap, but the entire string is rendered into the page, so a 50 MB scanned document becomes a roughly 70-million-character string and a visibly sluggish tab. At that scale, question whether Base64 is the right transport at all — a link to the file stored somewhere usually is.
base64-to-pdf reverses this exactly and validates the %PDF header on the way back. For non-PDF files, the file-to-base64 converter does the same job for any type.