How Images Are Stored: Pixels, Kids and Pixel Art

The moment this activity earns its keep is when your kid hands over a string of a hundred 0s and 1s, you sit at a blank grid without ever seeing their drawing, and the picture appears under your pencil. That is how images are stored as pixels, and kids get it instantly once they have done the decoding themselves. Then it gets better: you shorten the code using a real compression trick, measure how much shorter it got, and then draw a picture where the same trick makes the file bigger. Nobody teaches that second part, and it is the honest half.

Key Takeaways

• You’ll colour a grid, write the picture as 0s and 1s, and have a second person rebuild it from the digits with no sight of the original.
• Then you compress the code with run-length encoding, measure the saving, and find an image where compression makes things worse.
• It teaches pixels, bits per pixel and resolution, plus the fact that no compression method shrinks everything.
• Best from 7. The ideas land earlier than that, but transcribing 100 digits without losing your place is the real skill barrier.
• Write one grid row per line of digits. Every reconstruction failure traces to a lost place in the string.

What You’ll Need

Item	How much	Where to get it	If you don’t have it
Squared or graph paper	6 sheets	School supplies	Rule 10 by 10 grids with a ruler, about 1 cm squares
Pencil and eraser	1 each	Anywhere	Pen works but errors stay visible
Black marker or crayon	1	Stationery	Shade squares solidly in pencil
Three coloured pencils	Red, green, blue	Pencil case	Any three contrasting colours
A second person	1	The house	Do the decoding yourself after a ten-minute gap
Paper for the code	2 sheets	Anywhere	Lined paper is better; the lines keep rows apart

Time: setup 10 min, encode and decode 30 min, compression 20 min Cost: nothing Mess level: low

Do the Experiment

Step 1 – Draw two blank 10 by 10 grids

One for the artist, one for the decoder. Keep them identical and number the rows 1 to 10 down the side. The numbering is not decoration: it is what stops the decoder going wrong on row seven.

Step 2 – Colour a simple picture, one square at a time

A letter, an arrow, a smiley face, a heart. Rule: a square is either fully black or fully white, nothing in between. That rule is the whole concept of a pixel and it is worth stating out loud. Do not let the decoder see this grid.

Step 3 – Write the picture out as 0s and 1s

Go along each row left to right. White square, write 0. Black square, write 1. Put each row on its own line, so you end up with ten lines of ten digits. Count them: 100 digits for 100 squares, one bit per pixel.

Step 4 – Hand over only the digits and rebuild the picture

The decoder takes the digit sheet and a blank grid and fills it in. They must not see the original. This takes about five minutes and it is the step the whole activity exists for: a picture travelled between two people as nothing but numbers.

Step 5 – Compress it with run-length encoding

Rewrite each row as a list of run lengths, always starting with the count of white squares. The row 0011111000 becomes 2, 5, 3. Do all ten rows this way and count how many numbers you wrote in total. Compare with 100.

Step 6 – Now draw a checkerboard and compress that

Colour alternate squares black and white across the whole grid. Encode it as 0s and 1s, then run-length encode it. Each row becomes 1, 1, 1, 1, 1, 1, 1, 1, 1, 1: ten numbers per row instead of ten digits, so the “compressed” version is no smaller and, once you count the commas, is bigger. Measure it, do not just say it.

Step 7 – Change the resolution, twice

Redraw the same picture on a 5 by 5 grid and then a 20 by 20 grid. The 5 by 5 version loses the shape, and the 20 by 20 is recognisable from across the room. Count the squares in each: 25, 100, 400. Four times the detail costs four times the storage.

Step 8 – Add colour with two bits per pixel

Pick four colours and assign each a two-digit code: 00, 01, 10, 11. Colour a new 10 by 10 picture and write out the code. It is now 200 digits for 100 pixels. The relationship between how many colours you can have and how many digits each pixel costs is now something they have counted rather than been told.

What you should see: A correct reconstruction, provided the digits were written one row per line. If the rows run together into a single 100-digit blob, expect the decoder’s picture to be sheared diagonally, which is a spectacular and instructive failure. Run-length encoding on a simple shape typically cuts the code to 30 or 40 numbers, a real saving of over half. On the checkerboard it produces 100 numbers plus 90 commas, which is unambiguously worse. That contrast is the result worth getting to.

What’s Actually Going On: How Images Are Stored as Pixels

A digital image is a grid of pixels, and each pixel is stored as a number. That is all a bitmap is. The grid size is the resolution, and the number of bits used for each pixel is the bit depth, which sets how many distinct colours a pixel can have. One bit gives two colours. Two bits give four. Eight bits give 256. The 24-bit colour used by most screens gives 2²⁴ = 16,777,216, which is where the phrase “millions of colours” comes from.

Multiply those together and you get the size of an uncompressed image, which is worth doing once with real numbers. A 12-megapixel phone photo has 12 million pixels. At 24 bits, which is three bytes, that is 36 million bytes, about 36 MB. The JPEG on your phone is probably nearer 3 MB. Compression is doing an order of magnitude of work on every photo you take.

Run-length encoding is the simplest real compression method, and it is lossless: you get back exactly what you put in. It works by storing runs of identical pixels as a count instead of individually, which is why it pays off handsomely on drawings with large flat areas and fails on anything detailed. The checkerboard is the clean demonstration of failure, and it points at something deeper.

Here is the part that is genuinely rarely taught, and a ten-year-old can follow it. No compression method can make every file smaller. Suppose a lossless scheme turned every possible 100-bit input into a shorter output. There are 2¹⁰⁰ possible 100-bit inputs, and far fewer possible outputs shorter than 100 bits, so two different inputs would have to share an output, and you could not tell which one to restore. Lossless compression is therefore always a trade: it shortens the files you expect to see and lengthens the ones you do not. That is why there are different formats for photos, drawings and text, and it is why a zip of an already-zipped file gets slightly bigger.

Two more honest details. Real photo formats like JPEG are lossy: they throw away detail your eye is poor at noticing, which is why a heavily compressed photo develops blocky smudges and why repeatedly saving a JPEG degrades it. And not all images are grids at all. A vector image stores instructions, “circle here, radius this”, which is why a logo stays sharp at any size while a photo does not. CS Unplugged, the long-running unplugged computing project at the University of Canterbury, builds its image representation unit on exactly the grid-and-code activity above, which is good evidence it survives contact with real classrooms.

How to Explain It to Your Kid

Ages 5–8: squares are either on or off

Do steps 1 to 4 and nothing else. Use the words “on” and “off” rather than 1 and 0 at first, then swap. The sentence that does the work is: “A picture on a screen is just a list of which squares are on.” Then let them be the decoder, which is the better job, because the picture appearing from numbers is the magic part. Keep the grid at 8 by 8 to shorten the transcription.

Ages 9–12: count the bits and compress

Introduce bit as one 0 or 1, and get them to count. One hundred squares, one hundred bits. Then do run-length encoding and have them compute the saving as a fraction. The checkerboard comes next, and it should be presented as a challenge: “find a picture where my clever trick makes things worse.” Letting them hunt for it is far better than handing it over, and they usually find stripes or a checkerboard within a few minutes.

Ages 13+: bit depth, file sizes and the counting argument

Do the arithmetic for a real photo: 12 million pixels times 3 bytes equals 36 MB, against a JPEG of about 3 MB. Then give them the counting argument for why no scheme compresses everything, and ask them to write it in their own words. Then set the investigation: encode five different images, measure the run-length saving for each, and rank them. A pattern emerges about what kind of picture compresses well, and it is the same pattern that makes screenshots small and photographs large.

The question to ask: “I have invented a compression program that makes every file at least one bit smaller. You can run it again on its own output. What is wrong with my invention?”

Why Teaching This Early Pays Off

Children grow up surrounded by images and told nothing about what they are. “A photo is a list of numbers” is a one-sentence demolition of the idea that a screen is magic, and it opens the door to everything else: why screenshots are small and photos large, why a zoomed-in picture goes blocky, why a game’s graphics have a resolution setting.

The specific payoff is the trade-off. Resolution against file size, colours against bits, compression against fidelity. Engineering is mostly trade-offs, and this is the cheapest place a child can meet one and measure both sides. Jeannette Wing’s account of computational thinking puts exactly this kind of representation-and-trade-off reasoning ahead of learning to code, and the Framework for K-12 Science Education would call the grid a model being used to explain a phenomenon.

The caution is the usual one, plus one specific to this topic. One afternoon of grids does not make a child better at computing or at school, and nobody should claim otherwise. And the activity only works if you do the decoding step properly: handing over the digits while the decoder can still see the picture turns it into colouring in. Alfieri and colleagues found guided discovery works and unassisted discovery does not, and the guidance here is you, refusing to look at the drawing.

Before You Start: What Parents Should Know

Best age	7 and up. The concept lands at 5 with an 8 by 8 grid, but copying a 100-digit string without losing your place is the real floor, and that arrives around 7.
Supervision	You are the decoder, and your job is not to peek. The whole demonstration collapses if you can see the original.
Real hazards	None. Paper and pencil, no screen needed.
Setup	A table, and ideally two seats facing away from each other for the encode and decode steps.
Frustration point	Step 4, transcribing and decoding. Ten lines of ten digits is fine; one blob of 100 digits is a disaster. Enforce the one-row-per-line rule before they start writing.
Don’t	Don’t let anyone shade a square halfway, and don’t skip the checkerboard. The half-shaded square breaks the pixel idea, and the checkerboard is the only part that tells the truth about compression.

When It Doesn’t Work

• The decoded picture is sheared or scrambled. The digits were written as one continuous string, so the decoder lost the row boundaries. Rewrite with one row per line and number the rows.
• The two grids are different sizes. Both people must use exactly 10 by 10. A nine-wide grid against a ten-wide code produces a diagonal mess that looks like a bug in the method rather than a measuring slip.
• The run-length encoding comes out longer on a simple drawing. Check that every row starts with the white count, writing 0 first if the row begins with black. Without that convention the decoder cannot tell which colour a run is.
• The compression saving looks unimpressive. The picture has too much detail for a 10 by 10 grid. Try a large block, a border or a thick letter. Then compare against the detailed one and you have a real finding.
• A young child stalls on transcription. Drop to an 8 by 8 grid, and let them call out the digits while you write. The decoding is the part they should do themselves.

Take It Further

Rank five images by how well they compress. Encode a solid square, a thick letter, a diagonal line, a spiral and a checkerboard, and record the raw bit count against the run-length count for each. Plot the saving. The pattern, that flat regions compress and detail does not, is exactly why a screenshot of text is a small file and a photo of grass is a large one.

Do colour properly with three grids. Use separate red, green and blue grids, each with four brightness levels coded as two bits, and overlay them by colouring lightly in sequence. You have built a crude RGB image and you can count its total bits: 10 by 10 by 6 bits equals 600. That is how a screen actually works.

What to Watch For Over the Next 3 Months

• Week 4: They notice pixels in the wild, usually in an old game, a zoomed photo or a poorly scaled logo, and name them.
• Month 2: The idea of file size connects to something practical, like why a video would not send or why a photo had to be shrunk.
• Month 3: The question worth encouraging is how a photo gets so much smaller as a JPEG. The honest answer is that it throws away detail permanently, which is a good thing for a child to know before they edit and re-save a picture ten times.

Frequently Asked Questions

What grid size works best?

Ten by ten. It gives 100 pixels, which is enough for a recognisable shape and few enough to transcribe in five minutes. Eight by eight is better for under-8s. Twenty by twenty looks much better but takes four times as long to write out.

Why does compression sometimes make a file bigger?

Because no lossless method can shrink every possible input. There are more possible long inputs than short outputs, so any scheme that shortens some files must lengthen others. Run-length encoding shortens pictures with flat areas and lengthens pictures with fine detail, like a checkerboard.

How many bits does a real photo use per pixel?

Usually 24, which is 8 bits each for red, green and blue, giving 16,777,216 possible colours. A 12-megapixel photo at that depth is about 36 MB uncompressed, which is roughly ten times larger than the JPEG your phone actually saves.

Does this need a computer?

No, and it is better without one. The whole point is that the child performs the encoding and decoding by hand, so the representation stops being invisible. CS Unplugged built a widely used classroom unit on exactly this principle.

---

About the author

Ricky Flores is the founder of HiWave Makers and an electrical engineer with 15+ years of experience building consumer technology at Apple, Samsung, and Texas Instruments. He writes about how kids learn to build, think, and create in a tech-saturated world. Read more at hiwavemakers.com.

---

Sources

1. CS Unplugged, University of Canterbury. “Image Representation.” https://www.csunplugged.org/en/topics/image-representation/
2. CS Unplugged, University of Canterbury. “Binary Numbers.” https://www.csunplugged.org/en/topics/binary-numbers/
3. Wing, J. M. (2006). “Computational thinking.” Communications of the ACM, 49(3), 33–35. https://doi.org/10.1145/1118178.1118215
4. Alfieri, L., Brooks, P. J., Aldrich, N. J., & Tenenbaum, H. R. (2011). “Does discovery-based instruction enhance learning?” Journal of Educational Psychology, 103(1), 1–18. https://doi.org/10.1037/a0021017
5. Chi, M. T. H., & Wylie, R. (2014). “The ICAP Framework: Linking Cognitive Engagement to Active Learning Outcomes.” Educational Psychologist, 49(4), 219–243. https://doi.org/10.1080/00461520.2014.965823
6. National Research Council. (2012). A Framework for K-12 Science Education. National Academies Press. https://doi.org/10.17226/13165

Related reading: binary numbers taught with physical activities, coding without a computer, and a binary search game for kids.