What Actually Breaks Between Frontends

Most portability failures are mechanical, not creative. The usual suspects:

• Unresolved macros. {{char}}, {{user}}, {{random}}, and {{pick}} are handled inconsistently. Some frontends expand them at load, others at render, and a few leave the literal string in the bubble.
• Markdown dialect drift. Nested emphasis, HTML tags, and hard line breaks render differently depending on the sanitizer. Raw <br> may survive in one client and be stripped in another.
• Whitespace loss. Leading spaces, double blank lines, and trailing newlines get normalized. Indented dialogue or ASCII spacing evaporates.
• Quoted-speech conventions. Frontends with different defaults for narration vs. dialogue styling will reformat *action* and "speech" inconsistently.
• Length assumptions. A 400-word greeting that reads as a cinematic opening in one UI becomes a wall of text in a narrow mobile bubble.

None of these require you to dumb down the writing. They require you to write within a conservative subset.

The Portable Greeting Checklist

Before shipping a card, run the greeting through this list:

Check	Why it matters
Macros limited to {{char}} and {{user}}	Broadest support; avoid {{random}} in the first message
Plain Markdown only (*, _, **)	No HTML, no tables, no code fences
Single blank line between paragraphs	Survives whitespace normalization
No leading indentation	Indented blocks get flattened
Speech in quotes, action in asterisks	The de facto convention across frontends
150–250 words	Fits mobile bubbles without truncation
Ends on an open beat	Gives the user a clear turn to take

The macro rule is the one people violate most. {{random}} in a greeting seems clever until a frontend renders it literally, and now Captain Elara Voss is greeting you with {{random::hello::greetings}}.

Writing the Featured Greeting: Captain Elara Voss

Take a sci-fi card — Captain Elara Voss, a starship commander with a dry wit and a classified past. A portable opening for her looks like this in structure:

1. One sensory anchor. A single concrete detail: the hum of the bridge, the cold of the viewport glass.
2. One line of action. What she’s doing when the user arrives.
3. One line of dialogue. Her first spoken beat, in quotes.
4. One hook. A question, a problem, or an order that demands a response.

That’s four moves in under 200 words. It reads as a scene in SillyTavern, survives the MiniTavern renderer, and doesn’t collapse in a Chrome extension popup.

Example skeleton

*The bridge lights dim as the ship drops out of warp. Captain Voss
doesn't turn from the viewport.*

"Report."

*She taps the console once, waiting.*

Note what’s absent: no nested formatting, no macros beyond the implicit character identity, no HTML. The {{char}} reference is handled by the card’s name field, not the greeting body — that’s the single most reliable portability trick.

Character Card Hygiene for Cross-Frontend Greetings

The greeting is one field in a larger card. Keep the surrounding metadata portable too:

• Store alternate greetings as separate fields, not appended to the primary one. Frontends that support alternate_greetings will offer them; those that don’t will simply ignore them.
• Keep the first message self-contained. Don’t reference lorebook entries that may not load — assume only the card’s description and personality are present.
• Avoid frontend-specific directives. System-prompt overrides, [OOC] blocks, and injection tags belong in the card’s advanced fields, not the greeting.
• Test in at least two renderers. SillyTavern plus one mobile or browser client catches 90% of issues.

For roleplay cards with multiple openings, this discipline pays off: your alternate greetings become a menu of scene starters that work everywhere, rather than a set of paragraphs that only render correctly in the tool you authored them in.

Conclusion

Portable greetings are a constraint problem, not a creativity problem. Restrict yourself to plain Markdown, {{char}}/{{user}} macros, and a 150–250 word scene, and your character cards will behave identically whether they’re imported into SillyTavern or opened in a mobile app. If you want to test that portability directly, the MiniTavern character card market is a practical second renderer — cards load in the iOS and Android apps, the web tavern, and the Chrome extension, so a greeting that survives all four is genuinely portable.