How to Import a Character Card Into Another Platform
Character cards exist so a character can move between apps. In practice moving one works, but rarely without losing something, because there is no single authority enforcing the format. This guide covers the two export formats, the import paths you will meet, what typically gets dropped, and how to check the result before you invest in a long conversation.
What you are importing
There are two ways the same character travels, and they are not interchangeable.
| Format | What it is | Read by |
|---|---|---|
| PNG card | A normal image with the character data embedded in the file's own metadata | Clients that read embedded card metadata |
| JSON card | The character as plain text in a documented structure | Clients that accept a pasted or uploaded file, and anything you script yourself |
The useful detail is that a PNG card is only a picture to software that does not know how to read the metadata. Upload it to a client without that support and you get an avatar with no character. Character cards explained covers the fields and the format's history.
Because support is uneven, always export both. Both of this site's tools do this in one click: the card builder and the cultivation studio each write the PNG with the data inside and the JSON beside it.
The import paths you will meet
Roughly in order of how well they work:
- Upload the PNG in the character-creation screen. The most common route. The client reads the metadata, fills its form fields, and shows you a preview. Check the preview — it is showing you exactly which fields it recognised.
- Upload or paste the JSON. Often the more reliable route, because the client is explicitly asking for structured data rather than parsing image metadata. Some clients accept the JSON wrapper as-is; others want only the inner data object. If one fails, try the other.
- Paste the fields by hand. Tedious but it is the route with the highest fidelity, because you see every field as it lands and can fix what the import mangled.
- No import at all. Some products have no import, or hide it behind a paid tier. That is worth knowing before you build a library in one place.
What typically gets dropped
Import failures are rarely total. The pattern is that a subset of fields survives, and the client tells you nothing about what it ignored.
| Field | What usually happens on import |
|---|---|
| Name, description, first message | Almost always survive; these are the fields everything supports |
| Personality | Usually survives, sometimes merged into the description |
| Scenario | Often dropped, especially where the client has no equivalent setting |
| Example dialogue | Frequently dropped, or truncated, because it is the largest field |
| Tags | Usually survive as metadata; occasionally discarded |
| Creator notes | Usually treated as your private notes, and sometimes not shown to anyone |
| Alternative greetings | Dropped by most clients |
The practical rule that follows: make the description carry the character on its own. If the personality, scenario and example dialogue all vanish, the description is what is left — so anything essential belongs there, in prose, rather than only in the fields that get thrown away.
What breaks after a successful import
Even when every field lands, the character can feel different in its new home. Three causes, and only the first is about the card:
- Token budget. A long card is a fixed cost on every message. A client with a smaller context budget may truncate your card before it truncates anything else, and the character quietly loses its later paragraphs.
- Filter differences. Content allowed on one platform is routinely blocked on another, and the same card can be refused, silently moderated, or played in a much more restricted register. This is a property of the destination, covered in how content filters work.
- Model and template differences. Different clients wrap the card in different system instructions. The same card can produce a crisp character in one and a bland one in another, with no change to the file.
How to verify an import properly
Do this before you have twenty messages you care about:
- Read the import preview and compare it against the source card field by field. Note what is missing.
- Send two or three messages that require a specific trait. A character claimed to be blunt and formal should sound that way immediately. If it sounds generic, a field was dropped.
- Ask it something only the description covers. That isolates whether the description survived truncation.
- Check the name and the greeting. A wrong greeting means the first message did not import, which is the one field that most changes the opening of a conversation.
- Fix the file, not the chat. If something is missing, add it to the source card and re-import rather than trying to correct it through conversation.
If the character still feels wrong after all five checks, the destination is the problem, not the card. Rewriting it again usually does not help — see why characters break character for the mechanisms involved.
Should you import, or rebuild?
Import is usually worth it when the card has a long description and a specific voice, because retyping loses nuance.
Rebuild by hand is usually better when:
- The card is short. Retyping a five-field character takes two minutes and guarantees it lands.
- The destination drops most fields, so you are effectively retyping anyway.
- You want the character adapted to that platform's conventions rather than copied. A character written for long-form roleplay often needs shortening for a chat-oriented client.
Both routes are legitimate. What is not worth doing is importing, noticing halfway through a good conversation that the voice is wrong, and trying to patch it live.
Keeping a card library you can actually move
- Keep the source files, not just the imported copies. A folder of JSON cards plus their PNGs is the only version you control. Platforms change, and accounts close.
- Name files predictably. The character name and a version, so a later edit does not silently overwrite the one you liked.
- Version your edits. When you rewrite a character, keep the previous card. Character edits are usually a matter of taste, and taste changes back.
- Do not rely on a platform's public library as your backup. A published card is not a file you hold, and the platform's rules can change around it. If you want portability, download the character as a card as well as publishing it.
For where a finished card can go, and how the destinations differ, see the platform comparison. Where a card is imported into an all-in-one 18+ platform — HottyChat is one such destination, operated by the same team as this site — expect the same field-support questions to apply; test before you commit to a long chat.
Key takeaways
- Two formats travel: a PNG with the data embedded in its metadata, and a plain JSON card. Export both.
- A PNG card is just an image to any client that cannot read the embedded metadata.
- Name, description and first message almost always survive; scenario, example dialogue and alternative greetings frequently do not.
- Make the description self-sufficient, since it is the field that has to carry the character alone.
- Even a clean import can change the character, because of token budgets, content filters and how each client wraps the card.
- Verify with two or three probing messages before investing in a long conversation.
- Keep the source card files yourself — a published character on a platform is not a backup you control.