Elysia Tools
Navigation
Workflow Playbook
Inspect HTML email metadata, review fragile attributes and image references, create a reviewer-safe fallback copy, and render a shareable PDF proof.
Hubs
A broad HTML conversion workflow would overlap with generic extraction and cleanup work that already belongs elsewhere. The useful version of html-convert is narrower: take the actual HTML email or campaign fragment that stakeholders must approve, inspect the metadata and fragile attributes that influence review, and turn that source into a portable proof artifact.
Start by reading the document signals that a screenshot hides. Meta tags can reveal the intended title, preview text, social sharing text, or canonical assumptions. Attribute extraction helps surface link targets, image alt text, widths, tracking hooks, and other details that can break compliance or QA approval even when the visual layout looks acceptable. Image source extraction matters because a PDF proof is far less helpful if the underlying assets point to the wrong environment or missing filenames.
Not every HTML email is readable in raw form. Old table-based markup, inlined styles, and vendor snippets can make review painful. In those cases, convert to Markdown to isolate the real copy and hierarchy, then rebuild a simplified HTML review version only if the team needs a clean intermediate proof. That fallback is for comprehension, not for pretending the source was clean all along.
Finish by choosing the PDF path that matches the approval question. If design fidelity matters, render with the more precise HTML-to-PDF path. If the organization archives HTML mail proofs through office tooling, use the LibreOffice conversion path and label it accordingly. The final package should make it obvious what was reviewed, what was simplified, and what still requires live inbox testing outside this workflow.
Workflow playbook
Extract title, description-style metadata, canonical hints, social tags, and critical element attributes so the review starts from real document signals rather than screenshots alone.
List image sources, then strip nonessential tags in a separate pass to expose whether the message still carries the compliance copy, CTA labels, and visible hierarchy reviewers care about.
Convert the HTML into Markdown for readable editorial review, then reconstruct a simplified HTML proof when the original email markup is too brittle or overloaded for non-technical reviewers.
Produce the shareable PDF proof with the renderer that matches the acceptance goal, keeping clear notes about whether the output represents browser-style fidelity or office-style email conversion.
If the goal is to pull article text or clean arbitrary HTML for reuse, use `html-content-extraction-cleanup-and-delivery` instead. Stay here only when the result must be a reviewable proof or email-delivery artifact.
Choose PDF-first rendering when spacing, hero art, and footer placement matter. Use the Markdown round-trip only when the original HTML is too noisy for reviewers and a readable fallback copy is acceptable.
Use `html-to-pdf-precise` when browser-like layout fidelity is the main concern. Use `libreoffice-html-mail-to-pdf` when the team wants an email-oriented office conversion path for archive or handoff.