How fast can browsers process base64 data?
15 points
6 days ago
| 3 comments
| lemire.me
| HN
conradfr
11 minutes ago
[-]
I remember in the early days of Phoenix LiveView on an intranet app using http1 I noticed it was faster to base64 encode an image, putting it in an img tag and sending the diff through the Channel websocket than the regular http request through Cowboy.
reply
adzm
41 minutes ago
[-]
https://chromium-review.googlesource.com/c/v8/v8/+/7208125 v8 changed yesterday to avoid the temp buffer which will likely double the base64 decode speed.

Looks like this was brought up there as a result of this article too, which is neat! And helpful since I was just messing with a node script that is heavily decoding base64

reply
danhau
6 days ago
[-]
> However, when decoding, we must handle errors and skip spaces.

This had me scratching my head. Why would a base64 decoder need to skip spaces? But indeed, MDN documents this behavior:

> Note that: The whitespace in the space is ignored.

JS never ceases to surprise. Also, check out that typo :D

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

reply
wvbdmp
1 minute ago
[-]
Probably so you can put in line breaks? Seems common in base64 data, such as armored PGP keys or emails attachments. HTML attributes allow line breaks, although I haven’t seen it done for base64 images.
reply
cluckindan
6 days ago
[-]
So technically it’s now possible to hide a payload in somewhat human-readable text, as long as it base64-decodes.
reply
recursive
6 minutes ago
[-]
Now? There's no change. Also human readable text substantially consists of letters. But that's most of the base64 alphabet too. So this isn't like steganography. All the letters in the human-readable words are valid base64 characters too. The only thing about this is that you get to choose where to put the spaces and newlines. You can't exactly construct arbitrary payloads starting from arbitrary messages.
reply
moomoo11
18 minutes ago
[-]
What do you mean hide a payload?

Base64 isn’t obfuscation or encryption.

reply