What is Base64? Encoding Explained

Decoded values. JVBERi0xLjcK decodes to %PDF-1.7 followed by a line break: the header a PDF file starts with, so content really carries the file bytes. YWdlbmN5MDc6VmlzYSNUZXN0MjY= decodes to agency07:Visa#Test26, the partner’s user name and password. 2LPYp9ix2Kk= decodes to the Arabic name سارة (Sara) when its bytes D8 B3 D8 A7 D8 B1 D8 A9 are read as UTF-8, and to exactly سارة when the same bytes are read as Latin-1. The two receipt references decode to 12 random bytes each; nothing readable is expected in them.

O1: defect in the gateway configuration. Base64 turns every 3 bytes into 4 characters and rounds the last group up. The largest allowed file, 5,000,000 bytes, is 1,666,667 groups, so content is 6,666,668 characters (with one "=" of padding) and the body is 6,666,668 + 72 = 6,666,740 bytes, above the gateway’s 6,000,000. The largest file that passes: 6,000,000 − 72 = 5,999,928 characters are left for content; 5,999,928 ÷ 4 = 1,499,982 whole groups; 1,499,982 × 3 = 4,499,946 bytes. With the sample’s 72 bytes of JSON, every valid file from 4,499,947 to 5,000,000 bytes is therefore rejected (family-book.pdf at 4,800,000 bytes needs a 6,400,072-byte body, while birth-certificate.pdf at 4,200,000 bytes encodes to 5,600,000 characters and fits), and the applicant gets the gateway’s HTML page instead of a usable error. Files over the limit get the wrong response too: a 5,000,001-byte file sent by the partner’s system, which has no app check in front of it, never reaches the service, so the FILE_TOO_LARGE error that DOC-4 requires is never returned.

In ISTQB terms the failure is the 413 for a valid file; the defect is a body limit sized for the raw file instead of the encoded request. Report it against the gateway configuration, with DOC-4 as the test basis. How to fix it is the team’s decision: raise the limit above the largest encoded body, with room for long file names, or upload files as binary (for example multipart/form-data) instead of Base64 in JSON, which also removes the overhead of a third. Add one note for the developers: 5,000,000 and 5,000,001 bytes both encode to 6,666,668 characters, so the size rule must be checked on the decoded bytes, never on the length of the Base64 string.

O2: defect in the Android app. A line break every 76 characters is MIME-style wrapping. RFC 4648 §3.1 says encoders must not add line breaks unless the specification that uses Base64 asks for them, and the contract does not; §3.3 says decoders must reject characters outside the alphabet unless the specification says otherwise. So the service’s 400 INVALID_BASE64 is correct, and iOS shows that the files themselves are fine. You can see the two kinds of decoder side by side: encode a small file with the Base64 encoder’s "Line wrap" set to "76 chars (MIME)" and paste the result into the Base64 decoder, which is tolerant: it ignores the line breaks and reports how many whitespace characters it skipped. The Documents service is strict, as the RFC requires by default. Fix: the Android encoder must produce the value on one line. Ask the API owner to write "one line, no whitespace" into the contract.

O3: defect in how the receipt link is built. The second reference contains "+". The link puts standard Base64 into the query string without percent-encoding, and the service reads the query string with form-encoding rules, where "+" stands for a space; it receives k7Qd2 fA9w1Z0LsE and rejects it. The URL decoder reproduces this: with "Decode + as space" on, k7Qd2+fA9w1Z0LsE comes out as k7Qd2 fA9w1Z0LsE. The first reference works only because it has no "+"; its "/" is legal in a query string but would break the route if the reference ever moved into the path. Because the references are random bytes, whether a link fails looks random too, which is why this kind of defect is often reported as intermittent. Fix: Base64URL (RFC 4648 §5) for the reference, so that k7Qd2-fA9w1Z0LsE and Lm0x8Qp_Vt2aKc3Q need no escaping, or percent-encoding the value so that "+" becomes %2B (the URL encoder shows it), which is easier to forget. Links already sent by e-mail must keep working after the fix: ask how old references will be accepted.

O4: security defect, and the most serious of the six because it exposes credentials. The header decodes in seconds to agency07:Visa#Test26, so the gateway log keeps the partner’s password in readable form for anyone who can read the logs, and production logs the same way. The developer’s comment is wrong: Base64 is an encoding with no key, not encryption, and HTTPS protects Basic credentials only in transit, not after they are written to a log. Report it with high severity, and in the report give the user name but mask the password. Expected fix: mask or drop the Authorization header in the gateway log and in any other log or monitoring tool that records headers, and rotate the exposed credential. Confirmation test: repeat the partner call and check that the log shows no credential; as regression tests, check the other headers that carry secrets, such as API keys and Bearer tokens.

O5: defect in the back office. The apps are right: 2LPYp9ix2Kk= is the UTF-8 encoding of سارة (4 characters, 8 bytes). The back office turns the decoded bytes into text with Latin-1, one character per byte, so D8 becomes Ø and B3 becomes ³, which gives سارة; setting the Base64 decoder’s "Decode text as" to "Latin-1 / binary string" reproduces it exactly. A run of Ø or Ù, each followed by another symbol, is the typical sign of Arabic UTF-8 read as Latin-1. Fix: read the decoded bytes as UTF-8. Test data for the confirmation test and the regression suite: an Arabic name, a Hindi name in Devanagari (3 bytes per character in UTF-8), a Latin name with an accent such as José (é is 2 bytes), a name with an emoji if the field allows it (4 bytes), and an ASCII-only name, which must stay unchanged.

O6: not a defect. Padding follows the file size, because Base64 works in groups of 3 bytes: 48,211 leaves a remainder of 1 when divided by 3, so the value ends with "=="; 120,005 leaves 2, so it ends with "="; 96,300 leaves 0, so there is no padding. (A quick check: a number leaves the same remainder when divided by 3 as the sum of its digits.) The lengths are 4 × (size ÷ 3, rounded up): 16,071 × 4 = 64,284, 40,002 × 4 = 160,008 and 32,100 × 4 = 128,400, about a third more than each file, as expected. Close the note as not a defect with this calculation, and keep the three files: together they cover every padding case.

Test values for the file size (2-value BVA). Requirement boundary: 5,000,000 bytes, accepted with 201, and 5,000,001 bytes, rejected with 413 and FILE_TOO_LARGE; send both directly to the API, as the partner’s system does, and not only through the app. Gateway boundary for the sample file name, a technical boundary that the requirement does not mention: 4,499,946 bytes (body exactly 6,000,000, accepted) and 4,499,947 bytes (body 6,000,004, rejected by the gateway today, accepted once the defect is fixed). Padding cases: three sizes whose remainders when divided by 3 are 0, 1 and 2, such as the O6 files. Also run the gateway boundary with the longest file name allowed, because every extra byte of JSON lowers the largest file that fits, and ask what DOC-4 expects for an empty file. Keep 4,499,947 and 5,000,000 in the regression suite after the fix.

Negative tests for content, each expecting 400 INVALID_BASE64 and nothing stored, as the contract reads today: line breaks or spaces inside the value; the Base64URL characters "-" or "_"; a character outside the alphabet such as "*"; a length that is not a multiple of 4 (padding removed); and an "=" in the middle of the value. A double-encoded file is valid Base64 whose decoded bytes are Base64 text (it starts with SlZCRVJp instead of JVBERi0): it should be rejected as not a PDF if the service checks the file content against mimeType, so ask whether it does. For the receipt reference: references containing "+" and "/", and "=" if references can change length; a reference with a space; a percent-encoded one (%2B); and a well-formed but unknown reference, which must return a client error, never a 500 (the extract does not say which one, so ask).

Questions for the API owner: Should the service accept or reject missing padding and whitespace, and can the contract say so explicitly? What is the longest file name allowed, since it moves the gateway boundary? Does the service check that the decoded bytes match mimeType? Will receipt references switch to Base64URL, and how will links already sent keep working? And for files of up to 5 MB, is Base64 inside JSON the right channel at all, given its overhead of a third?

If your numbers differ, check that you rounded the number of groups up for the encoded length and down for the largest file that fits, and that you added the 72 bytes of JSON.