Talk:Base64

message: The page currently is about two completely different things:
# the numeral system in base 64
# the base64 encoding
* Actually, I think that the numeral system should be "Base 64" with a space, but I am not sure. Anyway, I think that a split with a disabiguation page is in order. Paolo Liberatore (Talk) 15:05, 30 November 2005 (UTC)
replies: text: I'm not sure i'd call them completely different after all a binary file is really just a very big number if you think about it. The page describes a numeral system and then goes onto describe its uses I see nothing wrong with this structure. Plugwash 15:47, 30 November 2005 (UTC)
replies: text: I rather agree, particularly since the numeral system isn't particularly notable except for its use in the encoding.  —Ilmari Karonen (talk) 15:52, 30 November 2005 (UTC)
thread_title: Split

message: I updated recently this article to include the vast usage possible for Base64, including in freeware applications like Mozilla and Thunderbird.
The simplest of examples:
  C:\Documents and Settings\<UNAME>\Application Data\Thunderbird\Profiles\<PRNUMBER>.default
  type signons.txt
  mailbox://henrique@venus
  \=username=\
  ~
  *\=password=\
  TW9ua2V5
  <UNAME> stands for your username in a Windows XP distribution, for example.
The password can be easily decoded, and is: Monkey.
This does not detract nor diminishes the great software provided by Mozilla (subjective opinion I know... that's why I posted this opinion in this discussion article). The majority of users will not notice these security flaws, nor even bother their personal data is subject of Trojans in their desktops... that can be able to decode these passwords quite easily and deliver them worldwide.
Of course, both Mozilla and Thunderbird offer an option for symmetric cyphers (increasingly more difficult to decode) on all Managed Passwords.
I know this is not the right placeholder for software considerations: but I found outstandingly interesting to find even Mail User Agents (MUA) use the basic concepts of Mail-encoding (as is Base64 mainly used!) for obscuring plain-text passwords.— Preceding unsigned comment added by Henrique Moreira (talk • contribs) 00:25, 19 December 2005‎ (UTC)
:Unless the user is asked to enter a key then the ONLY purpose encrypting the key serves is to prevent someone accidentally remembering a password they shouldn't when poking around in a config file. If someone has access to the encrypted password then they almost certainly have access to the key as well! Plugwash 01:26, 19 December 2005 (UTC)
replies: text: It's my expectation that Mozilla consider the password as stored in clear text, and use Base64 not for 'encryption' but rather in case the password contains special characters (such as the space). Plugwash is right, of course, unless there's a key the password could easily be decrypted by reverse engineering the executable that reads it. 59.167.212.218 23:25, 4 August 2007 (UTC)
thread_title: Base64 in freeware applications

message: mIRC trojans often use Base 64 as mIRC has functions for this inbuilt: $encode(text,m) and $decode(text,m). The trojans are spread over /amsg (message to all channels) or private messages and rely on the naiv trust of the users. They try to make users run commands encoded in Base 64 by claiming things like it will get them the latest Matrix movie, or operator (administrator) status in a certain channel. Some of them comes in the form '//write somename $decode(Base 64 encoded script,m) || .load -rs somename' and installs a script that keeps spreading this code, and sometimes comes with a backdoor. Other Trojans hid the whole code by making use of brackets: //[ $decode(Base 64 encoded commands,m) ]' and can run any commands. Then there's the ones who make use of $findfile to execute commands and appearing to be a harmless /echo: '//echo $($decode(Base 64 encoded $findfile mostly executing /amsg $cb,m),2)' where $cb is the clipboard content which mostly is the command, and $(...,2) evaluates the $findfile decoded.Perhaps someone could add a note on this in the article. I have never written in a WP article and feel a bit lost.— Preceding unsigned comment added by 62.181.79.121 (talk • contribs) 23:01, 23 January 2006 (UTC)
thread_title:  mIRC trojans 

message: maybe mention
$ echo -n UUU|base64-encode  # NB: in some OSs the command is now (2019) just "base64".
VVVV
and say why, just for the fun of it.— Preceding unsigned comment added by 210.201.31.246) (talk • contribs) 21:47, 16 February 2006 (UTC
-Black Walnut (talk) 08:37, 3 August 2019 (UTC)
thread_title:  UUU becomes VVVV 

message: "This data encoding scheme is used to encode the UTF-16"
Is it really doing this? I doubt. It's encoding Unicode codepoints, just like utf-8, utf-16, ucs-2 do.— Preceding unsigned comment added by 84.92.248.233 (talk • contribs) 18:13, 17 June 2006 (UTC)
replies: text: The RFC for UTF-7 seems to actually date back to the days before supplementary characters so its no help, using UTF-16 surrogates would be the only sane way to support those planes in UTF-7 without massive changes but i do not know if current implementations do so. Plugwash 18:24, 17 June 2006 (UTC)
replies: text: UTF-7 is generally deprecated these days. Rootless 13:44, 18 June 2006 (UTC)
thread_title:  UTF, really? 

message: From the article:
As newlines are inserted in the encoded data every 76 characters, the actual length of the encoded data is approximately 135.1% of the original.
To the best of my knowledge, MIME defines a line break as the character pair <CR><LF> (in that order). Therefore, every 57 bytes from the source is expanded to 76 Base64 characters + <CR> + <LF>, or 78 characters. This gives an expansion of approximately 136.8%. —&bnsp;Thiadmer Riemersma (thiadmer at compuphase dot com)— Preceding unsigned comment added by 14:23, 8 August 2006 (UTC)
replies: text: Googling and reading the article newline seem to verify this, so I modified the article accordingly. –Mysid(t) 18:21, 8 August 2006 (UTC)
thread_title:  MIME Line breaks are <nowiki><CR><LF></nowiki> 

message: I felt the example wasn't quite as intuitive as it could be, so I created the table version. (Sometime reader, new to editing.) aes — Preceding unsigned comment added by 02:54, 19 August 2006 (UTC)
replies: text: The "Man" --> "TWFu" table is a great addition.  Thanks. — Omegatron 22:03, 27 December 2007 (UTC)

text: The groups are processed from left to right: 010011010110000101101110 → 010011 010110 000101 101110 → 1910 2210 510 4610. Anomie⚔ 03:51, 8 January 2013 (UTC)
thread_title:  Example 

message: Am I reading this wrong?
"Groups of 6 bits (6 bits have a maximum of 26 = 64 different binary values) are converted into individual numbers from left to right"
Looks like they're converted into individual numbers from right to left, not left to right. For example:
0 0 0 1 0 1 = 5
and
0 1 0 0 1 1 = 19
Ajkochanowicz (talk) 14:10, 7 January 2013 (UTC)
replies: text: The groups are processed from left to right: 010011010110000101101110 → 010011 010110 000101 101110 → 1910 2210 510 4610. Anomie⚔ 03:51, 8 January 2013 (UTC)
thread_title:  Left to right 

message: I have reverted the addition of the following material by user:Ultimater. I think there may be some merit in it, but I also think some more attention should be paid to style and formatting, before it is added to the article proper. E.g., use of whole-word capitalization, rethorical questions, sentences starting by "Notice...", "Remember..." and the like should be avoided or limited.--Niels Ø 11:31, 23 August 2006 (UTC)
thread_title:  Material added by Ultimater 

message: Also notice that the length of each of the outputs are multiples of 4. Not only  MUST  every base64-encoded string consist of an even number of characters, the number of total characters  MUST  be evenly divisible by 4. The reason is because base64 is used to represent an exact binary sequence of data in groups 8 bits.--Niels Ø 11:31, 23 August 2006 (UTC)
thread_title: Added before heading "An example"

message: Remember ;   The text doesn't need to be exactly 3 characters in length. Notice the usage of the padding character.
Text content  	M 	M 	M 	M 	M 	M 	M 	M 	a 	a 	a 	a 	a 	a 	a 	a 	 	 	 	 	 	 	 	 
ASCII         	77	77	77	77	77	77	77	77	97	97	97	97	97	97	97	97	 	 	 	 	 	 	 	 
Bit pattern   	0 	1 	0 	0 	1 	1 	0 	1 	0 	1 	1 	0 	0 	0 	0 	1 	0     	0     	 	 	 	 	 	 
Index         	19	19	19	19	19	19	22	22	22	22	22	22	4 	4 	4 	4 	4     	4     	 	 	 	 	 	 
Base64-Encoded	T 	T 	T 	T 	T 	T 	W 	W 	W 	W 	W 	W 	E 	E 	E 	E 	E     	E     	=     	=     	=     	=     	=     	=
Notice that the equals character (the padding character) is appended to the generated base64-encoded string and ONLY when there is an empty slot in the Text content. The padding character will NEVER appear in the middle or beginning of a base64-encoded string. The padding character can be totally OMITTED from your base64-encoded string and it will not harm the string's contents. The reason is because the number of un-used bits can be recalcuated. However it's always a good idea to include the padding character in your strings.
It's possible to have two padding characters but NEVER three:
Text content  	M 	M 	M 	M 	M 	M 	M 	M 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 
ASCII         	77	77	77	77	77	77	77	77	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 
Bit pattern   	0 	1 	0 	0 	1 	1 	0 	1 	0     	0     	0     	0     	 	 	 	 	 	 	 	 	 	 	 	 
Index         	19	19	19	19	19	19	16	16	16    	16    	16    	16    	 	 	 	 	 	 	 	 	 	 	 	 
Base64-Encoded	T 	T 	T 	T 	T 	T 	Q 	Q 	Q     	Q     	Q     	Q     	=     	=     	=     	=     	=     	=     	=     	=     	=     	=     	=     	=
Why won't you encounter 3 padding characters? Because the string is read 3 characters at a time and 3 padding characters would translate as 000000 000000 000000 000000 which is "AAAA" and can be totally ignored -- however feel free to add as many extra A's or padding characters to the end of your base64-encoded string as you wish.
Let's have a second look at our previous example base64-encoded string again:
----+---10----+---20----+---30----+---40----+---60----+---70----+---80----86
TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
Tell me, if you were to decode that string back into it's original ASCII form, how many characters would it consist of? How long would it take you to turn that into a sequence of 0's and 1's and to count the number of bits and divide it by 4 then calcuate the remainder so you know the number of unused bits? Who needs to count it!? Just count the number of padding characters at the end of the string (in this case one) and you will know the number of un-used bits (one padding character per every two un-used bits). Hence in this case, the length of the original string was 1 character short (the padding character is a blank slot) of being a multiple of three.--Niels Ø 11:31, 23 August 2006 (UTC)
thread_title: Added before heading "UTF-7"

message: If you understand how the top three rows are derived it is fairly straightforward. If yo look at the binary digits above the index column, the first 6 are 010011 which is 16+2+1 giving the decimal 19. Likewise the next 6 are 010000, which is decimal 16. These are the values in the index column.
If you take the set of characters from the article:
:"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
Use the 19 to index into here (starting with A as zero, B as 1, etc. and you get T, the character in the last row. Similarly 16 indexes to Q. Does the article need more step by step details? -- Q Chris 07:04, 19 April 2007 (UTC)
thread_title: How are the last two rows in the diagram derived?

message: What's up with this particular expression? It's the equivalent of hexadecimal, but it appears to be all wrong. Could somebody brake down this particular expression to the latin word roots it is made up from and fix the spelling please? --89.212.75.6 16:01, 24 February 2007 (UTC)
replies: text: Quadrosexagesimal is not the same as hexadecimal, it is base 64 as opposed to base 16. I am no linguist but I guess that quadro refers to the 4 and sexagesimal to the 60, as in hexadecimal the hex refers to six and the decimal to 10. Note the term Quadrosexagesimal applies to the definition of the mathematical base 64, not the Base64 encoding. IMHO Really there should be two articles current one does not separate the two completely different terms very clearly, though separating them would require a lot of work -- Q Chris 15:00, 19 April 2007 (UTC)
replies: text: It's not Latin. It's a neologism created in English by analogy of words like hexadecimal. My question is whether this is actually an English word (it's not in the OED), or an invention for Wikipedia. kwami 04:42, 27 September 2007 (UTC)

text: Actually, it should be quattuorsexagesimal, though that's still faux Latin. I'm deleting the word until s.o. can come up with a non-Wikipedia based source. kwami 04:49, 27 September 2007 (UTC)
thread_title: Quadrosexagesimal

message: The justification given for the URL variant of Base64 is unsourced and it doesn't really sound right:
:"Using a URL-encoder on standard Base64, however, is inconvenient as it will translate the '+' and '/' characters into special '%XX' hexadecimal sequences ('+' = '%2B' and '/' = '%2F'). When this is later used with database storage or across heterogeneous systems, they will themselves choke on the '%' character generated by URL-encoders (because the '%' character is also used in ANSI SQL as a wildcard)."
It is my understanding that the problem isn't with URL-escaping the data, it's with the interpretation of UNescaped base64 data in URLs.  Specifically, the / is used as a path separator, and + is typically converted to a space.  So you can't have a URL like http://example.com/base64-encoded-text-here because it will be mangled.  Both / and + are perfectly legal in a URL and there's no reason that a developer or toolset should automatically think to escape it.  In fact, it would be great if they did because their application would then unescape it and they'd end up with valid Base64 data again.
Further, the justification involving "database storage or across heterogeneous systems" choking on '%' sounds a bit odd to me.  Applications should be unescaping their URLs before using the data to begin with (bug 1), and back-ends should never be blindly using user-provided data directly in their queries (bug 2).  Any application that fits into this category has more serious problems to worry about, so it makes no sense to me why this should be used as justification for a URL-friendly version of Base64. —Fastolfe00 04:38, 25 October 2007 (UTC)
replies: text: We don't seem to have a source for either version of the explanation. I'd put a {fact} tag on it, but it seems that the whole article needs sourcing, not just that one point. On the other hand, if you know a source that backs you up, please put your explanation in the article. In my opinion, it makes more sense. -- trlkly 07:19, 15 April 2008 (UTC)
thread_title:  Justification for URL variant 

message: The article should be moved to Base 64.  Other bases have a space such as Base 24.  I know the encoding method is called base64, not base 64, but the former is based on the latter, not vice versa. - TAKASUGI Shinji (talk) 06:51, 21 November 2007 (UTC)
replies: text: Oppose I would oppose this move on the grounds that I reckon that most people finding this article will be looking for the base64 encoding mechanism rather than the mathematical base 64. Also the article is almost exclusively about base64 encoding, not the mathematical base. Why not create an article about the mathematical base 64 at Base 64 rather than having the redirect. Each article would naturally reference the other. -- Q Chris (talk) 08:38, 21 November 2007 (UTC)
replies: text: Then please separate Base 32 and Base32 too. - TAKASUGI Shinji (talk) 11:30, 21 November 2007 (UTC)
replies: text: Yes, I would go along with that -- Q Chris (talk) 14:12, 21 November 2007 (UTC)
replies: text: I've noticed this page has been renamed.  Now, if we divide it into Base 64 and Base64, I think it's better to move this article again to Base64 and create the new article Base 64.  What do you think? - TAKASUGI Shinji (talk) 01:01, 22 November 2007 (UTC)
replies: text: I have moved it back! There is no justification for moving a page that is almost entirely about base64 to base 64. You are quite correct, it makes sense for this article to be called base64 and a new article about the mathematical base 64 should be written.  —Preceding unsigned comment added by Q Chris (talk • contribs) 08:06, 22 November 2007 (UTC)
replies: text: I have separated Base64 and Base 64. - TAKASUGI Shinji (talk) 10:30, 22 November 2007 (UTC)
replies: text: Good stuff, thanks -- Q Chris (talk) 12:28, 22 November 2007 (UTC)
thread_title:  Requested move 

message: It is the largest power-of-two base that can be represented using single printable ASCII characters.
I'd have thought that base 128 would hold that honour, and that base 64 is used because it's the largest power-of-2 base that can be represented using characters that are pretty much certain to have the same value on different systems. Thoughts? --wintermute (talk) 21:20, 14 December 2007 (UTC)
replies: text: There are 95 printable ASCII (not Extended ASCII) characters, and since BASE95 isn't a power of 2, I guess it's true.  —EncMstr 21:37, 14 December 2007 (UTC)
thread_title:  Is this true? 

message: May I use JavaScript base64 implementation given in the article in GNU GPL software legally? Does anyone have an idea, where this code comes from? Thanks. Dadudadu (talk) 12:58, 20 March 2008 (UTC)
replies: text: Although I hate to be unhelpful, I can't answer either question. The first would be giving legal advice, which Wikipedia can't do, and the second I don't know the answer. What I can tell you is that there are implementations of base64 that are released under the GPL available, so you might want to consider using one of those. -- trlkly 07:10, 15 April 2008 (UTC)
thread_title:  JavaScript Code Sample Usage 

message: This article needs citations. It's not necessarily inaccurate, but it has only one citation, and that is for an relatively insignificant point. So I have added the  tag, as I feel it is the most accurate representation of what this article needs, i.e. both citations and footnotes. -- trlkly 07:31, 15 April 2008 (UTC)
thread_title:  Citations Missing Tag 

message: I'm looking at the C code, and it looks like it can write one byte beyond the specified end of the output buffer:
      result[resultIndex++] = base64chars[n0];
      if(resultIndex > maxResultLength) return;
      result[resultIndex++] = base64chars[n1];
      if(resultIndex > maxResultLength) return;
      // one more instance omitted for brevity
The problem is that it writes to the output buffer before it checks for overflow.  For example, suppose maxResultLength == 0.  (Yes, this is a dumb value, but the same argument will apply regardless of the value.)  It will write the value to result[0], increment resultIndex to 1, then notice it is too big and return.  I am pretty sure it should be:
      if(resultIndex >= maxResultLength) return;
      result[resultIndex++] = base64chars[n0];
      if(resultIndex >= maxResultLength) return;
      result[resultIndex++] = base64chars[n1];
      // and the third instance of writing to result[] should be fixed likewise
If I am missing something and this is not really a bug, will someone please let me know?  Otherwise I will fix the code, test it, and edit this article accordingly.  CosineKitty (talk) 16:54, 13 May 2008 (UTC)
thread_title:  Apparent buffer overflow bug in C code 

message: There is no relationship between "Base 64" and "Base64" -- they refer to different concepts and the names, as given, are appropriate to each. Please don't merge them and close this discussion. Thanks!  —Preceding unsigned comment added by 69.3.26.236 (talk) 05:23, 24 June 2008 (UTC)
replies: text: Merge and redirect I don't care which spelling is used, but one should be a redirect to the other.  —EncMstr (talk) 07:29, 28 May 2008 (UTC)

text: Merge and redirect as per EncMstr, also for Base 32 into Base32 (I just edited Base32, and needed Base64 in UTF-1). --217.184.142.41 (talk) 11:30, 3 June 2008 (UTC)

text: Don't merge - The previous decision to split was voted on and decided. Merging these would be as sensible as merging Georgia (country) and Georgia (U.S. state) on the grounds that someone who knew no geography might look up the wrong one. The concept of the mathematical base 64 is not the same as the encoding mechanism. -- Q Chris (talk) 07:31, 24 June 2008 (UTC)

text: Don't merge - Base 64 shouldn't be called Base64.  If you think Base 64 is too short, you should try to delete it and remove it from the base list. - TAKASUGI Shinji (talk) 07:52, 24 June 2008 (UTC)

text: Merge and redirect The articles should be merged and Base 64 should be redirected to Base64 on the basis that Base 64 encoding is the only practical use of the Base 64 number system. The number system is only relative with respect to base64 encoding, I mean the only thing worth putting on a page dedicated to the base 64 number system would be its use in base64 encoding, therefore it should not have its own page. --Herecomesgibson (talk) 22:07, 18 July 2019 (UTC)
thread_title:  Proposal for merging 

message: no padding - just concatenate
following is my own selection (g and CRLF)
one padding = substitute with "g" (32) - magically gives space (32 hex 20)
two padding == substitute with "0K" (zero K) (52 10) - magically gives CRLF
Example:
[Man] => [TWFu]
TWFuTWFu -> ManMan
[Ma] => [TWE=]
TWEgTWFu -> Ma Man
[M] => [TQ==]
TQ0KTWFu -> M(CRLF)Man
KrisK  —Preceding unsigned comment added by 69.116.75.194 (talk) 06:46, 19 December 2008 (UTC)
thread_title:  Merge two base64 encoded strings 

message: This does not seem a good idea. The two subjects, Base 64 and Base64 encoding, are very different. Merging the two would only result in replacing two clear and concise articles with a single unneccessaraly long and confusing article.  —Preceding unsigned comment added by 194.221.133.226 (talk) 11:27, 26 June 2008 (UTC)
thread_title:  Response to Proposal for merging 

message: Because that is (afaik) the specification for the Base64 encoding we all know and love.
http://www.ietf.org/rfc/rfc1521.txt
Specifically, this article could benefit from inclusion of the table in section 5.2. Base64 Content-Transfer-Encoding, of said RFC that lists all allowed characters.  —Preceding unsigned comment added by 84.233.191.62 (talk) 13:16, 26 August 2009 (UTC)
thread_title:  This article should reference RFC 1521 

message: I noticed the Index Table didn't look right, since the last row (containing just the 'pad' character) didn't have the right number of columns and wasn't accounted for in the "colspan" counts. I fixed these issues and it looks better for me. I hope I didn't break it for anyone else -Ilikeimac (talk) 20:22, 18 May 2010 (UTC)
thread_title:  Index Table Formatting 

message: Isn't Base64 used in WordPress Malware Attacks? not kidding — ECat200 (talk) 12:01, 31 December 2010 (UTC)
replies: text: As binary attchments to e-mail are a very common way of spreading viruses, and base64 are used for binary attchments to e-mail, it means that base64 can be associated with computer virus. But that is guilt by association. We could equally well say forbid computers since they can get viruses. base64 is only a method to encode binary data and very useful, so we should not criticize it just for that. --192.138.116.231 (talk) 14:53, 29 April 2011 (UTC)
thread_title:  Huh? 

message: The padding example, "Input ends with: any carnal pleasure" is absolutely hilarious, but is it really appropriate for Wikipedia's audience? Should a cleaner example string be selected perhaps?
Buzzert (talk) 07:38, 24 September 2012 (UTC)
replies: text: You don't like Thomas Hobbes' Leviathan? Anomie⚔ 16:08, 24 September 2012 (UTC)
thread_title:  Carnal pleasure 

message: > One case where padding characters are required is when multiple Base64 encoded files are concatenated.
That is not true. Concatenate two strings whose length = 0 mod 3 and you will get no padding either way: you will need to somehow delimit (prefix with length, custom separation character, ...). Whichever method you choose, it has to be compatible with base64 strings without padding, thus it can also be applied to non-mod-3 non-padded cases.
The explanation given in the next sentence:
> The 2011 DEF-CON Capture the Flag (CTF) qualifiers[5][dead link] contained a puzzle with a file of concatenated Base64 encoded files.
That is backwards: they (apparently) chose files with a size not divisible by three. Then, yes, bare concatenation works, but not in all cases.
Padding is never strictly necessary.
--46.190.82.146 (talk) 13:12, 26 November 2012 (UTC)
thread_title:  False: padding required for concatenation 

message: If this is really a WikiProject Computing page and supposed to teach about computer science, then it should mention that embedded in the descripton of converting 8 bit to 6 bit numbers is the assumption that the 8 bit numbers be treated as Big Endian.  Wikipedia has a nice web page on that for reference.  — Preceding unsigned comment added by Alwhaley (talk • contribs) 15:48, 18 April 2013 (UTC)
replies: text: Endien-ness of bytes is only of concern to data transmission engineers. As far as computer operations are concerned bytes are atomic. Therefore base64 makes no assumption as to endin-ness, apart from the notational convention that left shift operations increases power and right-shift decreases. -- Q Chris (talk) 16:29, 18 April 2013 (UTC)

text: The algorithm is described in terms of concatenating binary strings, which uses the universal convention that numbers are written with the most significant digits first. You could equally write a definition using mathematical operations that is not bit order dependent. BTW the order of bits in a byte is abstracted to most significant first in every computer; have you ever come across a computer where shift left in either assembler(lsh) or a high level language (<<) divides by two? -- Q Chris (talk) 07:40, 7 May 2013 (UTC)
thread_title:  Big Endian 

message: I removed the  template requesting the article to be simplified by combining sections, which had been inserted two years ago.  The  template near the top of the article takes care of the problem nicely, because the table of contents can be collapsed and hidden if it becomes intrusive, yet the section anchors remain, making it easy to find content.  At least, that's the way it works now for desktop computer users; the way mobile device users see it may be different, but that may change in the future, depending on how the Wikipedia mobile interface is implemented. — QuicksilverT @ 15:17, 5 February 2015 (UTC)
thread_title:  TOC limit 

message: @Skintigh Thanks for your edit (diff). I actually checked it carefully using my editor to count the characters and to make a new string with the required ASCII text, and I cannot see how I stuffed it up—I guess I was checking the wrong version. Anyway, it's good now. Johnuniq (talk) 02:39, 20 May 2015 (UTC)
thread_title:  Unencoding 

message: The Javascript code computes: StringBuilder out = new StringBuilder((in.length * 4) / 3);
But the correct formula should be (((in.length+2)/3)*4) to get the ceiling of (in.length/3)
in-len	original formula	expected
0     	0               	0
1     	1               	4
2     	2               	4
3     	4               	4
4     	5               	8
5     	6               	8
6     	8               	8
Zyxxel (talk) 19:18, 9 March 2016 (UTC)
thread_title:  Wrong formula for size of output data for Javascript encode code 

message: I found that the C code was weird, so I tried to compile it: it doesn't under gcc and clang.163.5.121.48 (talk) 19:14, 15 September 2017 (UTC)
thread_title:  The C code does not compile 

message: I've removed the "Coding Paradigms" section. For an article such as this one, pseudocode seems like it would be the most appropriate way to demonstrate the concepts. This article does not need an in depth discussion of the trade offs of various C and JavaScript implementations. Those discussions should happen in language-specific forums.—C45207 | Talk 23:17, 17 November 2017 (UTC)
replies: text: I've removed this section again, as it had been restored by 216.172.42.58 without substantive improvement. For example code, we should have something more like "An implementation of a base64 encoder in pseudocode is" followed by pseudocode. The external links section would be a good place to link to multiple different implementations in various languages. For reference, the removed text begins "As an example of a small naive program stub to improve time performance (but not space), consider these quasi C code base64 functions...". —C45207 | Talk 02:42, 30 November 2017 (UTC)
thread_title:  Removed "Coding Paradigms" section 

message: I initially clicked the article thinking it would be only about the number system and was confused when I found out otherwise. I would like to suggest the title be changed to something along the lines of "Base64 Encoding" to avoid confusion --Herecomesgibson (talk) 22:18, 18 July 2019 (UTC)
thread_title:  The name of the Article should be changed to avoid confusion 

message: “RFC 3548 […]  attempts to unify […] the seldom-used Base32 and Base16 encodings.” Base16 is hexadecimal. By what standard is hex “seldom used”? Doug Ewell (talk) 20:40, 11 October 2019 (UTC)
replies: text: Isn't  more relevant? Regarding your last question, hexadecimal is probably much more often mentioned and used than Base64. Google statistics would probably "confirm" this. BernardoSulzbach (talk) 00:25, 14 October 2019 (UTC)
replies: text: I think it is ambiguous grammar, the "seldom used" referring to base32 only, not base32 and base16. I will try to make it clearer -- Q Chris (talk) 09:08, 14 October 2019 (UTC)
thread_title:  Seldom-used Base16? 

message: I want to become a administrator De123abcedx (talk) 04:58, 30 October 2021 (UTC)
replies: text: Please answer the questions on your talk page first. ClaudineChionh (talk – contribs) 05:26, 30 October 2021 (UTC)
thread_title:  Semi-protected edit request on 30 October 2021 

message: In case there are future disagreements about the alphabet used for encoding, I am recording what Base64#Variants summary table says:
*RFC 4648 §4 base64 (standard)
*RFC 4648 §5 base64url (URL- and filename-safe standard)
The above links define two alphabets:
*base64 A–Za–z0–9+/ 
*base64url A–Za–z0–9-_ 
These alphabets are defined with A representing 0, B representing 1, ... 0 (zero) representing 52 etc.
Some recent edits were reverted as they erroneously changed the order. Similar edits occurred at Base62 where the situation is much less clear because there is no standard encoding. Johnuniq (talk) 06:18, 8 November 2021 (UTC)
thread_title:  Base 64 alphabet 

message: This article assumes that bits within a byte are "naturally" counted from higher to lower. That's far from obvious and far from what's generally used. That also applies to the base32 article.  — Preceding unsigned comment added by 2A02:2F0E:DE01:9100:B3C7:3CBE:48E8:E99B (talk) 09:02, 28 July 2022 (UTC)
replies: text: Notating digits from highest to lowest significance left to right can very well be assumed to be the 'natural' order as it is used in the vast majority today (at least in English which is this site's language). One thousand is generally written as decimal 1000 and not 0001. Please compare to Positional notation for more information. --Zac67 (talk) 10:12, 28 July 2022 (UTC)
thread_title:  ASSumed bit big-endianness