Skip to main content
4 of 4
added 21 characters in body
Flater
  • 56.3k
  • 8
  • 106
  • 157

TL;DR
The key takeaway here is that there is a world of difference between the number 65535 and a piece of text which represents the digits '6', '5', '5', '3' and '5'. It may look the same to you when rendered on a computer screen, but to a computer internally, they are completely unrelated to one another.

The rest of this answer is a lengthy elaboration on what that means and how it is used in everyday computing.


Data has a type. For example, this answer is a text type, known to developers as a string. A number is a different type. There are several number types, based on what it is you're storing (int for integers, uint for positive integers, long for bigger integers, float or double for decimal values, ...).

Why do data types matter? Well, it's sort of similar to why we have file extensions.

Based on the file extension, the file data gets read in a different way. You can easily test this by taking an .mp3 file, changing its extension to .txt, and opening it. You'll see that your OS opens your text editor, not your media player, because it bases its choice on the file extension of the file you're trying to open.

In that text editor, you'll see characters. It's not readable, but as far as your text editor is concerned, this is all valid. You can remove some characters, add some more, and save the file.
If you now change the extension back to .mp3 and play it, you'll notice that the file is damaged. Maybe it's totally broken, maybe it only has a small glitch in it; this depends on what you changed and how you changed it.

Cool trick:
Take a Microsoft Office file (.docx or .xlsx, not the older versions), change its file extension to .zip, and open it. Lo and behold, this is a perfectly working zip archive! Since the advent of the .docx (instead of .doc) and .xlsx (instead of .xls) filetypes, Office has really been storing all of its data using ZIP archiving methods.

Any file is really just a long sequence of binary digits. And how we interpret those digits is at our discretion. ASCII text encoding is one of these interpretations. It uses a character library of 256 characters, which means that it can get away with using a number (0-255) to denote a single character, and this number handily fits into the space of a single byte. So when a text file is opened, the text editor takes the file data, takes the data one byte at a time, interprets that byte as a number (which inherently ranges from 0-255, and then shows the character for that number.

As an aside, I could write my own file data interpretation. For example, I could use a file's data to generate an image which is 1px tall and is as many pixels wide as the file has bits, and generate a black pixel for every 1 and a red pixel for every 0 in the file data. It's a bit of an odd system, but perfectly viable if I choose to make an application that generates these kinds of images.

Or, alternatively, I could store my students' pass/fail on an exam using a simple stream of bits where 1 is pass and 0 is fail, and I know the order of my students based on some other data I've stored somewhere else (not in this file). This is a highly efficient storage mechanism in terms of data size, but it is also very inflexible in terms of storing additional information (e.g. absentees).

Back to ASCII. You can do this exercise by hand using an ASCII table to look up character values. If your file's first byte is 0100 0001, which is 65 in decimal, the text editor will give you an A character.
Following this, you can figure out what 5 letter word I wrote here in ASCII: 0100 0001 0101 0000 0101 0000 0100 1100 0100 0101. If you take each byte, convert it to a number, and look up what character that is, you'll see that the 5 characters are APPLE.

One very important thing to notice in that linked ASCII table is that it doesn't just contain letters (a-z and A-Z), it also contains all digits (0-9).

You'll notice that this answer focuses on text, not numbers. There's a clue in your question:

However after typing in the number 65535 into a text document and looking up its file size (the "information" about the text doc) I got to see that the used storage for this document was actually "5 bytes"

The data you entered was parsed as text, not as a number. You did not store the numerical value of 65535, you stored the individual characters (i.e. text) of 6, 5, 5, 3, and 5. Using the ASCII table, this means that your file contains 0011 0110 0011 0101 0011 0101 0011 0011 0011 0101, which is the same as the APPLE example, but this time using the characters 65535.

Here's an online converter so you can play around with this (you can press "Swap" to switch converting to or from binary).


In programming terms, your variable type matters, because it indicates to the compiler how your data should be stored, and how it should be handled.

int myNumber = 65535;
string myString = "65535";

In the first case, it will store your value numerically. 65535 (decimal) is 1111 1111 1111 1111 in binary. However, int is always 4 bytes, so it gets stored as 0000 0000 0000 0000 1111 1111 1111 1111. Total size: 4 bytes.

In the second case, it will store each individual text character, which we already know from before is 0011 0110 0011 0101 0011 0101 0011 0011 0011 0101. Total size: 5 bytes.

Now here's an interesting curve ball:

int myNumberPlusOne = myNumber + 1;
string myStringPlusOne = myString + 1;

In the first case, because you're dealing with a number, the compiler does numerical addition, and stores the sum (65535 + 1 = 65536) as a new number. myNumberPlusOne is therefore stored as 0000 0000 0000 0001 0000 0000 0000 0000, which is a value one bigger than myNumber. Total size: still 4 bytes.

In the second case, because you're dealing with text, the compiler appends the 1 to the text. Now, you're storing a 6-character string, 655351, which in binary is 0011 0110 0011 0101 0011 0101 0011 0011 0011 0101 0011 0001. Total size: 6 bytes.

Here, you can see why data types matter. We store things differently, and we also treat that data differently. Why? Because it makes sense to us that + on numbers means numerical addition, whereas + on strings means string concatenation (= appending).


To summarize, the key takeaway here is that there is a world of difference between the number 65535 and a piece of text which represents the digits '6', '5', '5', '3' and '5'. It may look the same to you when rendered on a computer screen, but to a computer internally, they are completely unrelated to one another.

Flater
  • 56.3k
  • 8
  • 106
  • 157