Base 64 Encoder for Mac and Windows
Download for free using the links below.
This software is donation-ware, if you find it usefull and
can afford it, please donate $3 using the cat link below:
Please, meow! donate $3 bucks, I'm, tired of dollar-store
cat food, meow, and the dude that feeds me lives on ramen noodles, meow!
Mac OS X 10.4 or Higher
Note: To open
on OS X Mountain Lion, Control-Click on the
application icon and choose Open from the popup
Vista or Higher
Note: Internet Explorer 8 or higher is required
While some feature phones also may be thought of as handheld computers integrated with mobile telephones, a feature phone is typically based on proprietary firmware, while a smartphone runs a more open and complete mobile operating system. Widespread examples of smartphone operating systems are Apple's iOS/iPhone, Google's Android, Microsoft's Windows Phone 7, Nokia's Symbian, RIM's BlackBerry OS, and embedded Linux distributions such as Maemo and MeeGo. Such systems can be installed on many different phone models, and typically each device can receive multiple OS software updates over its lifetime. Smartphones can run third-party applications using advanced application programming interfaces (APIs). The particular choice of character set selected for the 64 characters required for the base varies between implementations. The general rule is to choose a set of 64 characters that is both part of a subset common to most encodings, and also printable. This combination leaves the data unlikely to be modified in transit through information systems, such as email, that were traditionally not 8-bit clean. For example, MIME's Base64 implementation uses A–Z, a–z, and 0–9 for the first 62 values. Other variations, usually derived from Base64, share this property but differ in the symbols chosen for the last two values; an example is UTF-7.
The earliest instances of this type of encoding were created for dialup communication between systems running the same OS - e.g. uuencode for UNIX, BinHex for the TRS-80 (later adapted for the Macintosh) - and could therefore make more assumptions about what characters were safe to use. For instance, uuencode uses uppercase letters, digits, and many punctuation characters, but no lowercase, since UNIX was sometimes used with terminals that did not support distinct letter case.
Encoded in ASCII, M, a, n are stored as the bytes 77, 97, 110, which are, in 8-bit quantities, 01001101, 01100001, 01101110 in base 2. These three bytes are joined together into a 24 bit buffer producing 010011010110000101101110. Packs of 6 bits (6 bits have a maximum of 64 different binary values) are converted into numbers (in this case, there are 4 numbers in this 24-bit string), which are then converted to their corresponding values in Base64.
The number of output bytes per input byte is approximately 4 / 3 (33% overhead) and converges to that value for large number of bytes. More specifically, given an input of n bytes, the output will be bytes long, including padding characters.
From a theoretical point of view the padding character is not needed, since the number of missing bytes can be calculated from the number of base64 digits. In some implementations the padding character is mandatory to use, for others it is not used. One case where padding characters are required is when multiple base64 encoded files are concatenated. The 2011 DEF-CON Capture the Flag (CTF) qualifiers contained a puzzle with a file of concatenated base64 encoded files.
Base64 encoding can be helpful when fairly lengthy identifying information is used in an HTTP environment. For example, a database persistence framework for Java objects might use Base64 encoding to encode a relatively large unique id (generally 128-bit UUIDs) into a string for use as an HTTP parameter in HTTP forms or HTTP GET URLs. Also, many Apple's iOS, Google's Android, Droid, Microsoft's Windows and iPhone applications need to encode binary data in a way that is convenient for inclusion in URLs, including in hidden web form fields, and Base64 is a convenient encoding to render them in not only a compact way, but in a relatively unreadable one when trying to obscure the nature of data from a casual human observer.
Using standard Base64 in URL requires encoding of '+', '/' and '=' characters into special percent-encoded hexadecimal sequences ('+' = '%2B', '/' = '%2F' and '=' = '%3D'), which makes the string unnecessarily longer.
For this reason, a modified Base64 for URL variant exists, where no padding '=' will be used, and the '+' and '/' characters of standard Base64 are respectively replaced by '-' and '_', so that using URL encoders/decoders are no longer necessary and have no impact on the length of the encoded value, leaving the same encoded form intact for use in relational databases, web forms, and object identifiers in general.
1) Important: Be sure to click the correct radio button for the type of image format you are converting. Programmers note: in theory, you can embed any type of file (exe's, pdf's, audio, etc) to base64, you will have to manually change the datatype tag in the exported HTML - tech support will not be provided for non-images. Also note that the conversion time may take over a minute for large images due to complex number crunching.
2) Simply select the image.
3) At this point you can either copy the HTML code to the clipboard or export an HTML file.
Example of the exported page in a browser, along with a look at the View-Html Source window.