# Extensions

Extensions are central to the success of AsciiDoc because they open up the language to new use cases. Asciidoctor provides an extension API that offers a superset of extension points. As a result, extensions in Asciidoctor are easy to write, powerful, and simple to distribute.

Asciidoctor also allows extensions to be written using the full power of a programming language (whether it be Ruby, Java, Groovy or JavaScript). You don’t have to shave yaks to get the functionality you want, and you can distribute the extension using defacto-standard packaging mechanisms like RubyGems or JARs.

## Available extension points

Asciidoctor provides the following extension points:

Preprocessor

Processes the raw source lines before they are passed to the parser. See Preprocessor Extension Example.

Tree processor

Processes the Asciidoctor::Document (AST) once parsing is complete. See Tree Processor Extension Example.

Postprocessor

Processes the output after the document has been converted, but before it’s written to disk. See Postprocessor Extension Example.

Docinfo Processor

Adds additional content to the header or footer regions of the generated document. See Docinfo Processor Extension Example.

Block processor

Processes a block of content marked with a custom block style (i.e., [custom]). (similar to an AsciiDoc filter) See Block Processor Extension Example.

Compound block processor

Register a custom block named collapsible that transforms a listing block into a compound block. See Compound Block Processor Example.

Block macro processor

Registers a custom block macro and processes it (e.g., gist::12345[]). See Block Macro Processor Extension Example.

Inline macro processor

Registers a custom inline macro and processes it (e.g., Save). See Inline Macro Processor Extension Example.

Include processor

Processes the include::<filename>[] directive. See Include Processor Extension Example.

There are additional extension examples in the Asciidoctor extensions lab.