Native base64 utility methods

Alexandre Morgaut Alexandre.Morgaut at
Fri May 16 00:13:51 PDT 2014

I give a +1 for native support of base64 encoding/decoding in ES

I actually did a basic polyfill like module to add support of the standard W3C atob() / btoa() API over browsers (they don't all support it) and servers (mainly tested on Wakanda and Node.js)

My main concerns were, as already mentioned in this thread:
- limitation to ISO strings
- explicit exclusion of binary support by the current specification (must throw an error)

I think there is 3 approaches for such API:
- 2 raw global methods as atob() and btoa(), potentially base64Encode() and base64Decode() or whatever
- 2 methods of a dedicated namespace as JSON.stringify() / JSON.parse(), potentially Base64.stringify() / Base64.parse()
- Dedicated prototype methods (base64Decode/base64Encode or fromBase64/toBase64) to each concerned constructors like:
-> String.prototype
-> Typed Array prototypes

I'm not fan of the first option (2 raw global methods)
I'll use the second option in a below but think the third one may be easier to extend binary format supports

In a perfect world I'd love to see something simple similar to (use the namespace approach in this sample):

Base64.stringify( any ) -> return a string
Base64.parse( string, format ) -> return expected instance object

where format could be either depending of this working group choice:
- a string specifying the expected returned format (ex: "Uint8Array", "Uint16Array"...)
- a reference to the constructor of the expected format (ex: Uint8Array)

my personal choice would be for the constructor reference for 2 reasons:
- while coding, the developer would have native autocompletion to fill this parameter value
- at runtime, an exception would be natively throw if the constructor is not supported by the environment (and then obviously by the parse() method)

As said, I care about extensibility of "binary format supports"
Fact the Typed Array will be native in ES6 is awesome to have some formats available by default
Still note that nowadays we also have:
- Blob, File, data URL (formated in base64), ImageData (canvas) from HTML5 standards
- Buffer in node.js, wakanda
- ByteString & ByteArray supported by some CommonJS platforms and by CommonNode

A registerFormatHandler( encoder, decoder) method could then be a plus

On 5 mai 2014, at 21:24, Florian Bösch <pyalot at<mailto:pyalot at>> wrote:

I'd like highlight the fact that binary data handling in JS these days is mainly done via ArrayBuffers and TypedArrayViews. To that end, I've written a base64 to Uint8Array decoder like so:

I don't quite see how atob/btoa without a usable binary type (indexable by byte, get the byte values out) should work.

On Mon, May 5, 2014 at 8:22 PM, Andrea Giammarchi <andrea.giammarchi at<mailto:andrea.giammarchi at>> wrote:
@john I don't really care about the namespace/module as long as this matter moves from W3C spec to ES one.

@mathias didn't mean to change atob and btoa rather add two extra methods such encode/decode for strings (could land without problems in the String.prototype, IMO) with "less silly names" whatever definition of silly we have ^_^

Also interesting the @claude info on ISO strings ... yes, any UTF-8 compatible support is what I meant, doing in JS land unescape(encodeURIComponent(str)) feels very hacky, and it's slow, indeed

take care

On Mon, May 5, 2014 at 8:16 AM, John Barton <johnjbarton at<mailto:johnjbarton at>> wrote:

On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi <andrea.giammarchi at<mailto:andrea.giammarchi at>> wrote:
+1 and as generic global utility it would be also nice to make it compatible with all strings.

A language with modules does not need nor should it rely on stuff more favorite features onto global.  We need standard modules for all new features.

[cid:a672ec.png at baf5850d.4983f3e1]
Alexandre Morgaut
Wakanda Community Manager
Email : Alexandre.Morgaut at<mailto:Alexandre.Morgaut at>
Web :<>

60, rue d'Alsace
92110 Clichy - France
Standard :      +33 1 40 87 92 00

es-discuss mailing list
es-discuss at<mailto:es-discuss at>

es-discuss mailing list
es-discuss at<mailto:es-discuss at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a672ec.png
Type: image/png
Size: 4628 bytes
Desc: a672ec.png
URL: <>

More information about the es-discuss mailing list