Cards

The Lightweight card

Make a website, app, program, etc. that’s under 5 KB! You can use compression, minification, etc!

Make a website or an app that is under 5 KB. Not minified-and-gzipped-and-we-rounded-down. Actually small.

This is a constraint card. The interesting part is not the number, it is what you start doing once every byte has to justify itself.

The size limit, precisely

Target 5 KB. That is the card’s requirement and what you should be aiming at.

A little over is tolerated. If you land at 6 or 8 KB having clearly fought for it, that passes. 16 KB is the hard ceiling, and nothing above it meets the card however good it is. Do not treat 16 as the target: a project that sails in at 15.9 KB and shows no sign of anyone caring about size is not what this card is for.

Measure the whole thing a user has to download to use it: HTML, CSS, JavaScript, images, fonts, everything. Say the figure in your README. Reviewers will check it.

Websites

The web is the easiest place to start, because the browser forgives an enormous amount.

Write it by hand. Any framework loses before you begin: React and its runtime are already several times over budget. No build step, no bundler, no dependencies. One .html file is a perfectly good architecture here.

Then start cutting:

Drop the optional tags. HTML does not need </p>, </li>, </td>, </tr>, <html>, <head> or <body>. The parser puts them back. Quotes around attribute values are optional when the value has no spaces.
Minify the JavaScript, then look at what the minifier could not do: long identifiers inside strings, repeated patterns, anything a shorter algorithm would avoid entirely.
Draw, do not download. An SVG you wrote by hand, a canvas, or a CSS gradient costs a fraction of any image file. If you need pixel art, generate it in code from a short string.
No web fonts. A font file alone will eat the budget. Use the system stack.
Compress. Gzip and Brotli are free and every host does them. State which figure you are quoting.
Pack code into a PNG. The classic demoscene trick: store your payload in an image and unpack it at runtime. Overkill for most entries, and very much in the spirit of this card.

The genre to look at is js1k and js13k, competitions built entirely on this constraint. The entries are a good education in what fits in a few kilobytes, which is much more than you would guess.

Windows executables

The compiler is your problem here, not your code. A default MSVC or GCC build wastes most of its size on runtime and headers before your program does anything.

Crinkler is the tool for this: a linker and compressor built for 4 KB demoscene intros that routinely gets real programs into a couple of kilobytes. It is the standard answer.
Do not link the C runtime. Set your own entry point, skip main’s setup, call the Win32 API directly.
No libraries. Every one you link drags in more than you will save by using it.
Failing Crinkler, UPX will compress an ordinary executable, though not nearly as far.

Linux executables

Same idea, different tools.

Compile with -Os, strip everything, and turn off the things that are silently included: -nostdlib, -fno-asynchronous-unwind-tables, -fno-stack-protector, -static.
Syscalls directly instead of libc. A static binary that talks to the kernel itself can be a few hundred bytes.
Hand-write the ELF header if you want to go all the way. There is a well-known lineage of articles on building a minimal ELF executable, ending somewhere near 45 bytes.
sstrip removes what strip will not touch.

Everywhere else

The card says “website or app”, and an app is whatever you can make somebody run.

A PICO-8 cart, which is size-limited by design.
An uxn or WASM-4 ROM, both tiny fantasy consoles.
A bootsector program in 512 bytes, which is the most extreme version of this card and genuinely achievable.
A QR code that contains the whole program.

What to put in your README

The final size, how you measured it, and whether it is compressed.
What you had to give up.
The trick you are proudest of.

That last one is the actual point of the card. The size is the constraint; what the constraint made you do is the project.

How it is reviewed

A reviewer checks the size against the limit above, then reads the description for how you got there. Size is objective, so this is one of the easier cards to be confident about before you ship: weigh it yourself first.