Code to PDF

190+, via a syntax highlighter. The major ones — JavaScript, TypeScript, Python, Ruby, Go, Rust, C, C++, C#, Java, Kotlin, Swift, PHP, HTML, CSS, SQL, Bash, YAML, JSON, XML, Markdown — all have excellent highlighting with accurate token recognition. Niche and historical languages are also covered: Haskell, Erlang, Elixir, Lisp variants, COBOL, Fortran, Assembly, VHDL, and many others. Auto-detect inspects the code and guesses the language based on syntax patterns; it gets the answer right about 95% of the time for files with distinctive syntax. For ambiguous cases (a plain .txt file with code-like content, or a custom DSL), override with the language picker to force the right highlighter.

Yes, but how wrapping behaves depends on the font size and page width. By default, lines longer than the page width wrap to the next line with no number on the wrapped portion (the line number applies to the logical line, not the wrapped visual line). This matches how IDEs typically display code. If you prefer no wrapping (so long lines extend past the page edge and require horizontal scrolling — useful for screen viewing but bad for printing), uncheck Word wrap. For maximum readability of long lines, reduce the font size or switch to landscape orientation. The tool numbers from 1 by default; you can override the starting number if you are converting a snippet that begins at line 47 of a larger file.

It depends on the theme. The default light theme (similar to GitHub's web syntax highlighting) uses dark text on a white background with moderately saturated keyword colors — it prints crisply on color or grayscale printers, and remains readable when printed as black-and-white because the contrast is dominated by darkness, not hue. Dark themes (Dracula, Monokai, etc.) look great on screen but print terribly because the dark background eats toner and the bright syntax colors lose readability when printed. For printing, always pick a light theme. For screen reading or PDFs that will only be viewed digitally, any theme works. Use Grayscale PDF after generating if you want to verify how the output looks without color.

Yes. The Header option lets you specify a string that appears at the top of every page in the PDF, typically the filename or a project descriptor. Combined with the line numbers, this is enough metadata for professional-looking code documentation — printed handouts in workshops, archived snippets in legal evidence collections, or appendices in technical reports. The header text is rendered as native PDF text (not part of the highlighted code image), so it stays searchable even if the code itself is rasterized. You can also add a footer for page numbers or copyright notices. Both header and footer are optional — leave them blank for unadorned code-only output.

Code to PDF uses the in-browser HTML renderer to render the highlighted HTML into images for embedding in the PDF, which is CPU-intensive for long files. Each page of the PDF requires the in-browser HTML renderer to render the corresponding lines, and for a 1,000-line file that may mean dozens of pages and dozens of render operations. Total time is typically 1-10 seconds for 100-line files, scaling roughly linearly. For very long files (5,000+ lines), conversion may take 30+ seconds — split the source into chunks before converting if needed, then merge the resulting PDFs. A future version may switch to native PDF text drawing for faster output without the the in-browser HTML renderer step, at the cost of some styling fidelity.

Partially. Because the output uses the in-browser HTML renderer rasterization, the highlighted code is embedded as an image and not directly searchable. The header text (if set) is native PDF text and is searchable. For fully searchable code PDFs, use Text to PDF with a Courier (monospaced) font instead — you lose the syntax highlighting but gain perfect text searchability. Alternatively, run the resulting Code to PDF output through OCR PDF afterward, which will add an invisible text layer over the rasterized code. OCR is not perfect on code (special characters and weird identifiers sometimes mis-recognize), but it makes Ctrl-F work for most identifiers. For the best of both worlds, archive both a Text to PDF version (searchable) and a Code to PDF version (styled).