I'm sure most of us have heard of zip bombs and similar decompression bomb tricks, where a maliciously crafted input creates a massively disproportionate output. We even had a question on here to do that to a compiler at one point.

Well, it occurs to me that Markdown is a compression format of sorts, replacing bulky HTML tags with "compressed" MD tokens. Therefore, might it be possible to build a compression bomb in Markdown?

Challenge rules:

The submission should be a piece of markdown text, between 50 and 256 characters in length. (Imposing a minimum to head off some smart-aleck posting a 3-character response or similar.)

The submission will be processed by StackExchange's Markdown processor as implemented in this site.

Your score will be the ratio of character count in the resulting HTML to the character count of your Markdown text.

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

11 Answers
11

Blockquotes, 137,469/256 = 536.99

6,908 characters, 511 new lines, 130,050 spaces

Markdown sure handles nested block-quotes oddly. Each > character gets turned into <blockquote></blockquote> so a solid 1 to 25 ratio. But wait! When rendering the HTML it also adds two spaces per nesting! Having this try to render causes my browser some grief, and I will keep it in the code-cage for now. Feel free to unlock it yourself!

The code input consists of 255 > followed by & as the last character doesn't transform, but it does get escaped. Thanks BWO! as the last character which gives the last blockquote the spoiler class with an empty p tag inside. Thanks bta, 11 extra characters

Now this is "arrow code" if I've ever seen it.
– ZeroKnightSep 21 at 6:42

3

Nice. This is quadratic growth because the j-th quote adds O(j) new characters, so we get big-O of 1+2+...+n = O(n^2). You can see this from the picture where the triangle's height is the number of quotes n and its width is O(n), so its area is O(n^2). The other non-Mathjax answers seem to be only linear growth (the billion-laughts MathJax one is exponential).
– usulSep 21 at 14:37

multiplies the gross inefficiency of representing exotic characters in MathJax by a considerable factor.

The StackExchange MathJax configuration limitation of 10\$\,\$000 macro expansions is being honored, while the limitations of the client’s browser, which are highly likely to cause problems expanding the macros, are not. (My browser is uncooperative as well, so the figure is an estimate.)

@RomanOdaisky Not at all. You've probably done the calculation yourself, and reached this conclusion. I'm just saying, as a math teacher and enthusiast, that it seems like it would be a cool exercise.
– ArthurSep 20 at 15:30

After the fixed overhead for creating the URL reference, each 5-character link expands into 42+strlen(url) characters output. Craft the URL to have the maximum number of characters that need escaping, and this grows to 47+3*strlen(url) characters per link. A little experimentation showed that the optimal output involved 26 links, with 114 carets per link.

Update:
If you interpret the "256 character" limit to include Unicode characters, you can squeeze out more chaos. Replacing the carets with the Unicode bathtub character (🛁, codepoint U+1F6C1) results in 47+18*strlen(url) output characters per input character for a total of 54,574 68,960 (thanks to jimmy23013's even-shorter link notation).

Caveat: The MathJaX only shows the error during editing, so you have to view it in the editor. This is still a markdown implementation on this site, so should be valid. Once posted the Misplaced & warnings turn into normal &'s.

We start with & because it expands to &amp; and use 0 next, alternating these constantly creates new <span> elements with a class attribute. Unfortunately we can't use only & or &<&<... since they stay in the same pun-<div>

If you look at the source code for this page, the HTML is just <pre class="lang-c prettyprint-override"><code>&amp;0&amp;0&amp; ... 0&amp;0&amp;0&amp; </code></pre> where ... is more of the same. The span tags aren't there at all. That's a score of 739/256 = 2.887
– Engineer ToastSep 19 at 20:56

@EngineerToast: What browser? I'm using Firefox 62 and they show up, I noticed with another answer that I get another score, so I guess this depends on the browser..
– BMOSep 19 at 21:04

190/50 = 3.8: Italics

As it turns out, your 3-character worry is true. *q* generates <em>q</em> giving a ratio of 10/3. Two carriage returns give <p>...</p>\n\n (the two carriage returns aren't necessary, but do appear to be produced) and a resulting ratio of 9/2. Total ratio, 19/5.

This abuses the fact that most markdown editors will replace the ampersands in the alt text with doubly-escaped ampersands in order for it to show up correctly. Meanwhile a single ampersand is tossed into the src section so that the parser will actually see it as an image.

Would ε be translated to &epsilon; or &#949;?
– Jonathan FrechSep 19 at 20:19

I don't know. As far as I can tell it doesn't actually work - debugging it a bit now. I used & because in theory for alt-text to show up correctly it has to be escaped twice (&amp;amp;). This works in most markdowns, but doesn't seem to produce any output at all in SE...
– LambdaBetaSep 19 at 20:20

Couldn't you compress this with [1]:https://& on a line, and then use ![&][1] more times?
– wizzwizz4Sep 20 at 20:35

Does it really have to be https? http would give you less unexpanded characters. Or ftp if that works.
– immibisSep 24 at 1:45

11190 / 255 = ~43.88

I was inspired by this top answer, but am too dumb to beat it and reached the max character count so, I guess I'll have to be satisfied with what I have ¯\_(ツ)_/¯. There's actually two spaces after the last blockquote, but the formatting does not show it.