Consider a fictional workshop handout containing a title, an emphasized arrival instruction, and a short equipment list. Its useful result is an editable document with those contents intact. A browser animation or responsive card layout has no role in that handoff.
Start with a small, explicit input
Install the package in a separate working directory and record the exact installed version in the lockfile:
npm install html-to-rtf
Save this as convert.cjs beside that installation:
const fs = require('node:fs');
const htmlToRtf = require('html-to-rtf');
const html = `
<h1>Field recorder workshop</h1>
<p>Arrive at <strong>09:15</strong> for the sound check.</p>
<p>Bring headphones, a recorder, and a charged battery.</p>
`;
const rtf = htmlToRtf.convertHtmlToRtf(html);
if (typeof rtf !== 'string' || !rtf.startsWith('{\\rtf')) {
throw new Error('Converter did not return the expected RTF header');
}
fs.writeFileSync('workshop.rtf', rtf, 'utf8');
Run it with node convert.cjs. The package's maintainer README documents convertHtmlToRtf and a separate file-saving helper. This example uses Node's own file API so the output path and write operation are visible. Node documents the file-writing API.
The header check catches an obviously wrong return value. It does not establish that every character, list, or layout feature survived. Open the actual saved file to make that decision.
Use a document check that matches your input
Open workshop.rtf in the receiving editor and check these original fixture expectations:
| Source detail | What to inspect in the opened RTF |
|---|---|
| Field recorder workshop | Title text remains present and legible |
| 09:15 in strong markup | Time remains exactly 09:15; emphasis is visible |
| Three equipment items in one sentence | No item disappears or merges into another word |
| Paragraph boundaries | Arrival instruction and equipment sentence remain separate |
Then add a second input containing characters you actually use, such as Málaga, an ampersand, and a person's real name supplied for the document. Verify the saved output in the destination application. A console printout containing plausible RTF control words is a different observation from the recipient successfully opening the document.
If the target application rejects the file, keep the failing input and installed package version. Reduce the input to the smallest paragraph that reproduces the problem, then compare that result before changing a production handout.
Keep the conversion within its supported scope
The maintainer lists supported tags and a small set of style properties. Treat external stylesheets, page layouts, custom fonts, images, and more complex document structures as separate acceptance questions. Do not infer full browser rendering from a few paragraphs converting successfully.
For example, an attendance table introduces cell order and row boundaries that the initial handout never tested. Add an original two-row fixture with identifiable values before using the converter for that table. If the destination requires DOCX instead, use the HTML-to-Word workflow and verify that actual format.
Keep the original HTML, the converter script, and the generated RTF together until the recipient confirms the document opens correctly. Make corrections in the maintained source and regenerate the file; editing a derivative without recording the change creates two different handouts.