Build a Markdown bomb

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

Input: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>!

Output HTML:

...
  <blockquote>
    <blockquote class="spoiler">
      <p></p>
    </blockquote>
  </blockquote>
...

Here is what it looks like in the editor view!

Plotting the results as the number of > increase as suggested by LambdaBeta:

MathJax, 529\$\,\$252\$\,\$640_ish / 256 ≈ 2\$\,\$067\$\,\$393

A good old thousand-laughs-style code

$$\def\a{}\def\b{\a\a\a\a\a\a\a\a\a\a\a\a\a}\def\c{\b\b\b\b\b\b\b\b\b\b\b}\def\d{\c\c\c\c\c\c\c\c}\d\d\d\d\d\d\d\d$$

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.)

Shorthand links: 68,960 / 256 = 269.375

ASCII only: 10,114 / 256 = 39.508

[][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1][][1]
[1]:ftp://^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Output is a sequence of elements that each look like:

<a href="ftp://%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E%5E" rel="nofollow noreferrer"></a>

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).

Unicode input:

[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1],[1]
[1]:ftp://

Output is a series of:

<a href="ftp://%EF%BF%BD%EF%BF%BD...per character...%EF%BF%BD%EF%BF%BD" rel="nofollow noreferrer">1</a>,