SVG to HTML

Modern LLMs are surprisingly decent at writing raw SVG markup - icons, simple diagrams, little vector illustrations - straight out of a text response. svg2html takes that raw SVG string and wraps it into a proper HTML document string, which matters more than it sounds: a bare <svg>...</svg> fragment isn't something most viewers, publishing APIs, or email/article renderers will happily accept on its own. Wrapping it in HTML is what makes it renderable somewhere else.

It's one of two ways this pack lets you do something with LLM-generated SVG. The other is svg2img_function, which rasterizes the same kind of SVG into an actual ComfyUI IMAGE for use inside a normal generation pipeline. svg2html is the path for when the destination is a webpage or a document, not the ComfyUI graph itself - and it lines up neatly with this pack's send_to_wechat_official node, whose content field explicitly expects HTML. An LLM writes an SVG diagram, svg2html wraps it, and it goes straight into a published article.

Inputs and outputs that matter

• svg_code - the raw SVG markup, typically straight from an LLM node's text output.
• html_str - the single output: an HTML string with the SVG embedded, ready to hand to anything that consumes HTML.

There's no configuration beyond that - this node does one specific reshaping job and nothing else.

Installing it

Search comfyui_LLM_party in ComfyUI Manager and install, or clone it manually:

cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party

pip install -r requirements.txt inside your ComfyUI Python environment, restart ComfyUI. This specific node has no model or API dependency of its own - it's string wrapping - but it ships as part of the full pack, which is a much bigger install (LLM API clients, local model support, RAG, TTS, and a long tail of tool nodes). If you only need API-based calling, the README's only_api branch skips the heavier local-model dependencies.

Common issues

The node trusts that svg_code is actually valid SVG. LLMs are good at this but not perfect - an unclosed tag, a stray bit of commentary the model added before or after the markup ("Here's the SVG:\n\nsvg\n...\n"), and you'll get a broken or unrenderable document on the other end even though svg2html itself won't error. If output looks wrong downstream, check the raw svg_code first rather than assuming the wrapping step is the problem - a tight system prompt telling the model to respond with SVG only, no commentary or code fences, fixes most of this at the source.

Beyond that, keep expectations realistic about what renders where: SVG features like filters, embedded fonts, or gradients that look fine in a browser preview may not survive being pasted into whatever platform ultimately displays this HTML (a WeChat article, an email client, a CMS). Simpler SVG - basic shapes and paths - travels far more reliably than anything visually fancy.