Inspired by both the challenge "Unique is Cheap" by @Laikoni, where the score is based on the challenge itself, as well as the JavaScript (ES6) answer of @ETHproductions for the "Palindrome Compression" challenge, where he uses a pretty cool compression method for the palindrome-flag, upper/lower case indication, and letters.


You will create two programs/function: a compress program/function, and a decompress program/function.

Compress program/function:

Given the characters used in your own source code (both the compress and decompress source code combined) as only possible input, use any kind of bit-compression method of your choice and output the resulting 0s and 1s of the bit-compression of this input.

The amount of bits (0s and 1s) outputted must be as short as possible, and this amount will be the score of your answer.

The idea is to have a nice balance between the different kind of characters used in your own source code, the size of your programs/functions, and the type of bit-compression you've used. Or to quote @RobertFraser in this comment:

This is a great example of the fundamentals of engineering. Taking a problem description, thinking about different ways to solve it, and making tradeoffs between requirements (ie how many bits to dedicate to various styles), etc

Challenge rules:

  • The compressor and decompressor program/function should be in the same programming language.
  • You must provide both a compression and decompression program/function, and the amount of 0s and 1s your compression program outputs for both programs/functions combined (concatted) as input will be your score.
  • The compression must - obviously - work for all characters used in your source code of both your compression and decompression program/function, in any order or amount. (It can have undefined behavior for any characters not in your source code.)
  • Input-type doesn't necessarily have to be a string. It could also be a list/array/stream of characters, and it can be as program argument, STDIN, etc. Your call.
    Same applies to the output. Can be returned from a function or printed to STDOUT. Can be a single string, integer-array, etc.
  • Your compression program must output at least one 0 or 1 (so an empty cat program for both the compression and decompression program isn't possible).
  • Your source code may not only contain 0s and 1s already, excluding no-ops (to prevent programming languages that print their own source code by default, where both the compression and decompression programs can be a single 0 or 1, and the no-ops part is to prevent this behavior with an unused comment; sorry binary-based programming languages which only use 0s and 1s as source code).
  • Although you'll have to support an input of 0 or more of the character-pool used in your programs/functions, you don't have to support an empty input. So you can assume every input will be at least 1 character.
  • A possible input can be larger than your compression and decompression sizes combined.
  • If for whatever reason your compression method is order-depended and has a shorter output when your input is DecompressionProgramCompressionProgram instead of CompressionProgramDecompressionProgram, you are allowed to choose either order of concatting of your programs/function for your score.


Let's say the compression program is ABC, and the decompression program is 123aBc. For any input containing zero or more of the character-pool 123ABCab, it should be able to correctly compress those characters to 0s and 1s, and be able to decompress these 0s and 1s back into the correct characters. Some valid example inputs for these two programs can be: ABC123aBc (of course); A; 1Ca; 22222b1121221b; etc.

General rules:

  • Standard rules apply for your answer, so you are allowed to use STDIN/STDOUT, functions/method with the proper parameters, full programs. Your call.
  • Default Loopholes are forbidden.
  • If possible, please add a link with a test for your code.
  • Also, please add an explanation if necessary.

Example of an answer:

Java 8, score 1440 bits, 180 (87 + 93) bytes

Here a very bad implementation in Java 8, where each character is simply printed as 8-bit binary String.

Compression function:

Input provided as java.util.stream.IntStream.

s->s.forEach(c->System.out.print("".format("%8s",Long.toString(c,2)).replace(' ','0')))

Try it online.

Decompression function:

Input provided as String.

s->{for(Integer i=0;i<s.length();System.out.printf("%c",i.parseInt(s.substring(i,i+=8),2)));}

Try it online.

  • \$\begingroup\$ This is not a quine test, so can I read my source code? \$\endgroup\$ Commented Mar 5, 2018 at 16:22
  • \$\begingroup\$ @WeijunZhou Depends on what you use it for, but I probably allow it in most cases. I guess you want to read your source code and then map easy of it's characters with a look-up table, or something like that? \$\endgroup\$ Commented Mar 5, 2018 at 16:53
  • \$\begingroup\$ Yes, something similar is on my mind. \$\endgroup\$ Commented Mar 5, 2018 at 16:54
  • 1
    \$\begingroup\$ I may have missed something, but here's a possible loophole in the rules: compressor->if input==compr_code+decompr_code then return 0 else return binary charcodes of input, decompressor->if input==0 then return compr_code+decompr_code else convert binary codes to characters and return them. Final score: 1 (lowest possible). The programs won't be trivial to write, but with some tricks from quines they surely are doable. \$\endgroup\$
    – Leo
    Commented Mar 6, 2018 at 8:15
  • \$\begingroup\$ @Leo Hmm, you're indeed right that the current rules allow such an answer (unintentionally of course). Not sure how to fix it, though.. I could state you must provide the mapping you've used for each individual character, which must correspond / be the same for the compressor + decompressor input as well as any random configuration of these characters. But in that case I might limit possible answers who want to compress pairs of characters, or whatever they come up with. Any suggestions on a rule to close this loop hole, but still leave some flexibility for creativity?.. \$\endgroup\$ Commented Mar 6, 2018 at 8:27

3 Answers 3


Jelly, score 350, 39 + 30 = 69 bytes

Compressor: Jelly, 39 bytes


Try it online!

Decompressor: Jelly, 30 bytes


Try it online!

  • \$\begingroup\$ @KevinCruijssen whoops. fixed, thanks \$\endgroup\$
    – hyper-neutrino
    Commented Mar 5, 2018 at 15:40
  • 1
    \$\begingroup\$ @KevinCruijssen oh I'm bad lol. thanks for the fix! \$\endgroup\$
    – hyper-neutrino
    Commented Mar 5, 2018 at 16:11

Java (OpenJDK 9), score 702 bits, 88 (42 + 46) bytes

Compressor, 42 bytes

$->new java.math.BigInteger($).toString(2)

Try it online!

Decompressor, 46 bytes

$->new java.math.BigInteger($,2).toByteArray()

Try it online!

  • \$\begingroup\$ Sorry, I'm playing the low byte-cost (hum, for Java, I mean) rather than the hard compression :S \$\endgroup\$ Commented Mar 5, 2018 at 15:44
  • \$\begingroup\$ Didn't even knew it was possible to put any String in the BigInteger constructor.. Figured it would give a NumberFormatException or something.. I did knew about the .toString(2). Nice golf of my example answer I guess. ;) \$\endgroup\$ Commented Mar 5, 2018 at 16:03
  • \$\begingroup\$ @KevinCruijssen Indeed, as it currently is, it's more a golf of your example than anything else. 703 bits means 88 bytes. I couldn't compress anything in less than 88 bytes so far, but I'm still trying to ;-) \$\endgroup\$ Commented Mar 5, 2018 at 16:10

Pyt, score 179 bits, 9+10=19 bytes



Try it online!



Try it online!

  • 1
    \$\begingroup\$ Decompressor still seems to throw an error \$\endgroup\$
    – Jo King
    Commented Mar 6, 2018 at 0:30
  • \$\begingroup\$ That's strange. It works when I run it locally. \$\endgroup\$
    – mudkip201
    Commented Mar 6, 2018 at 1:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.