Encoding fails to create a universally decodable base64 string about base64url

[allentc]

This implementation of URL safe Base64 is flawed and will yield invalid encoded values due to missing padding characters. The "general case" language should be assumed in this work.

RFC 4648 The Base16, Base32, and Base64 Data Encodings

3.2.  Padding of Encoded Data

   In some circumstances, the use of padding ("=") in base-encoded data
   is not required or used.  In the general case, when assumptions about
   the size of transported data cannot be made, padding is required to
   yield correct decoded data.

   Implementations MUST include appropriate pad characters at the end of
   encoded data unless the specification referring to this document
   explicitly states otherwise.

   The base64 and base32 alphabets use padding, as described below in
   sections 4 and 6, but the base16 alphabet does not need it; see
   section 8.

[shamas]

Buffer.from("fdsfdsafdsaff|https://cdsf.fdsf.fdsfsd.com/rep|https://lfdjsfjsdfj.fdskfjdsk.com/license").toString('base64');

[empjustine]

universally decodable base64 string

No such thing exists, RFC 4646 declares 2 incompatible dialects of base64:

• "Base 64 Encoding" https://datatracker.ietf.org/doc/html/rfc4648#section-4

• "Base 64 Encoding with URL and Filename Safe Alphabet", aka "base64url" https://datatracker.ietf.org/doc/html/rfc4648#section-5

The gnu util base64 -D is only capable of handling "Base 64 Encoding", and will choke on "Base 64 Encoding with URL and Filename Safe Alphabet" or "base64url", what this library uses.

You can't use base64 -D to decode the output from this library.