16.7 Exporting Code Blocks

It is possible to export the code of code blocks, the results of code block evaluation, both the code and the results of code block evaluation, or none. Org defaults to exporting code for most languages and results for inline code blocks. For some languages, such as ditaa, Org defaults to results both in ordinary source blocks and in inline source blocks. To export just the body of code blocks, see Literal Examples. To selectively export subtrees of an Org document, see Exporting.

The ‘exports’ header argument is to specify if that part of the Org file is exported to, say, HTML or LaTeX formats.


The default. The body of code is included into the exported file. Example: ‘:exports code’.


The results of evaluation of the code is included in the exported file. Example: ‘:exports results’.


Both the code and results of evaluation are included in the exported file. Example: ‘:exports both’.


Neither the code nor the results of evaluation is included in the exported file. Whether the code is evaluated at all depends on other options. Example: ‘:exports none’.

If a source block is named using ‘NAME’ keyword, the same name will be assigned to the results of evaluation. This way, fuzzy links pointing to the named source blocks exported using ‘:exports results’ will remain valid and point to the results of evaluation.

Results of evaluation of a named block can also be explicitly named using a separate ‘NAME’ keyword. The name value set via ‘NAME’ keyword will be preferred over the parent source block.

#+NAME: code name
#+BEGIN_SRC emacs-lisp :exports both value
(+ 1 2)

#+NAME: results name
#+RESULTS: code name

This [[code name][link]] will point to the code block.
Another [[results name][link]] will point to the results.

Explicit setting of the result name may be necessary when a named code block is exported using ‘:exports both’. Links to such block may arbitrarily point either to the code block or to its results when results do not have a distinct name.

Note that all the links pointing to a source block exported using ‘:exports none’ will be broken. This will make export process fail, unless broken links are allowed during export (see Export Settings).

To stop Org from evaluating code blocks to speed exports, use the header argument ‘:eval never-export’ (see Evaluating Code Blocks). To stop Org from evaluating code blocks for greater security, set the org-export-use-babel variable to nil, but understand that header arguments will have no effect.

Turning off evaluation comes in handy when batch processing. For example, markup languages for wikis, which have a high risk of untrusted code. Stopping code block evaluation also stops evaluation of all header arguments of the code block. This may not be desirable in some circumstances. So during export, to allow evaluation of just the header arguments but not any code evaluation in the source block, set ‘:eval never-export’ (see Evaluating Code Blocks).

Org never evaluates code blocks in commented subtrees when exporting (see Comment Lines). On the other hand, Org does evaluate code blocks in subtrees excluded from export (see Export Settings).