PDF files starts with "LS0tl" base 64 string cannot be opened on pdf.js browser

Question

I am using pdf.js to display pdf files in the browser. Content of pdf file is a base64 string.

If base64 string starts with "LS0tl" pdf.js cannot open it, but never had a problem with "JVBER". When I download pdf files, both files open without a problem.

Answer 1

Adobe Reader and many other PDF viewers are able to accept partially "off" normal standard PDFs. This includes there being some characters before the RECOMMENDED %PDF- that we now expect.

FROM the ISO standard (ISO 32000-2:2020(E))

7.5.2 File header
The PDF file begins with the 5 characters “%PDF–” and byte offsets shall be calculated from the PERCENT SIGN (25h).
NOTE 1 This provision allows for arbitrary bytes preceding the %PDF- without impacting the viability of the PDF file and its byte offsets.

Thus a PDF that starts with Base64 "Transmission Header" bytes as here or with 4 bytes prefix as currently added to some more recent PDFs by Google. Are perfectly acceptable on opening, SOME of the time by SOME Readers. Thus detectors that solely depend on JVBER are wrong to assume that it is the only Base64 prefix for a PDF in transfer.

Several times Adobe Reader (and other PDF viewing editors), will accept a file with odd start or endings and simply fix it for running. Then on close may ask if you wish to save as its edits.

Adobe Reader will accept this file header. Since meeting its specifications, without even asking if it should be rebuilt. And Google apparently say this is why they dispatch recent invoices with this type of variable encoded start to their PDFs.

We can sometimes use that ability to our advantage by modding a byte so as to trigger a different compression. Since "Acrobat Reader" will usually edit the whole file into a newer "Web Enhanced" format. Admittedly then it becomes JVBER at the start if converted to base64!

So will PDF.JS accept this type of PDF? And the 2025 answer is yes just like all others currently do. Since recently 2 PDF viewers I support had to be able to open those Google random header files !!

And JVBER is not an ISO mandatory prefix for files of this type.