Labs · Card format converter
v1, v2, v3 —
converted, with losses named.
Drop a card, pick a target version. Upgrades are lossless; downgrades tell you exactly which fields die before you download. And the three-generation difference table below settles the “what changed in v3” question for good.
Drop a character card here, or click to choose
.png / .json (V1 / V2 / V3 all accepted)
Conversion happens locally in your browser — nothing uploads, nothing is stored.
The conversion preview appears here.
The three generations, field by field
V1 (2018–2022) was six flat fields at the JSON top level. V2 wrapped everything in a data object and added the lorebook, alternate greetings and extension slots. V3 added identity and packaging: nicknames, assets, group greetings, decorators, and the charx container.
| Field / capability | V1 | V2 | V3 |
|---|---|---|---|
| name / description / personality / scenario | ✓ | ✓ | ✓ |
| first_mes greeting · mes_example dialogue | ✓ | ✓ | ✓ |
| creator_notes · tags · creator | — | ✓ | ✓ |
| system_prompt · post_history_instructions | — | ✓ | ✓ |
| alternate_greetings | — | ✓ | ✓ |
| character_book (embedded lorebook) | — | ✓ | ✓ |
| extensions (embedded regex etc.) | — | ✓ | ✓ |
| nickname (substitutes {{char}} in prompts) | — | — | ✓ |
| group_only_greetings | — | — | ✓ |
| assets (avatar / sprites / backgrounds) | — | — | ✓ |
| creator_notes_multilingual | — | — | ✓ |
| source · creation/modification_date | — | — | ✓ |
| lorebook decorators (@@activate etc.) | — | — | ✓ |
| .charx zip container (card + assets) | — | — | ✓ |
Field placement follows the three spec generations as implemented in SillyTavern 1.18. V1-era wild files often carry creator_notes and friends too — pre-spec extensions; this table files them where the spec does.
Where the mapping comes from
The field mapping mirrors the import pipeline we ship in the app, which was verified against 34 real community card files and the SillyTavern 1.18 source: a data object means V2/V3 (spec string decides which), no data object means V1 flat, string-typed list fields get wrapped instead of dropped, and talkativeness is clamped to 0–1 on promotion. The V3-only field list comes from the chara_card_v3 spec as implemented there — the same list the downgrade loss report enumerates.
What it won't do for you
It converts structure, not quality — a weak card is a weak card in any spec version. Frontends differ in how much V3 they actually implement, so after converting, test the card once where you plan to use it. And .charx containers aren't unpacked here; the checkup tool can read the card.json inside one, but repacking charx is app-side work.
FAQ
What actually differs between card v2 and v3?
V3 (chara_card_v3) keeps the whole V2 structure and adds: nickname (substitutes {{char}} in prompts), group_only_greetings, an assets list for avatars and sprites, multilingual creator notes, source links, timestamps, lorebook decorator syntax (@@activate and friends), and the .charx zip container. If a card uses none of those, v2 and v3 are the same card in a different wrapper.
What do I lose downgrading v3 to v2?
Only the V3-only fields the card actually uses — this page enumerates them per card before you download. Typical losses: asset references, nickname, group-only greetings, multilingual notes, source and timestamps. The persona text, greetings, example dialogue and the embedded lorebook all survive; decorator lines inside lorebook entries stay as text but V2 frontends read them as plain words.
Does converting change my card's content?
No. The converter moves structure, not prose: fields are re-filed between wrappers byte-for-byte. The two exceptions are mechanical and reported on screen — an empty V1 name defaults to "Unknown" (importer convention), and a V1 top-level talkativeness moves into extensions where V2 expects it.
My card has a data object but no spec field — what is it?
A semi-spec card, common from community exporters and hand edits. Most frontends read it as V2; strict validators reject it. Running it through this converter with V2 as the target normalizes it: same content, plus the spec and spec_version fields tools expect.