vCard parser, validator, editor and builder library for Rust
- All vCard versions: parse and write 2.1, 3.0 and 4.0 through a single, version-agnostic model.
- Byte-faithful editing: change one parameter or value and every other byte of the card, line endings included, is preserved exactly.
- Forgiving parser: accept any real card, even a malformed one, and round-trip it unchanged.
- Strict building and validation: construct cards checked against the standard, with an escape hatch when you need to step outside it.
- Small and portable: no_std compatible, with an allocation-only core that pulls in no dependencies.
- Optional content decoding: quoted-printable text, inline base64 binary and foreign character sets, each behind its own feature.
- Optional jCard: read and write a card as JSON.
- Optional JSContact: convert a card to and from the Card object exchanged over JMAP.
Tip
vcard-rs uses cargo features to gate optional support. The default feature set is declared in Cargo.toml or on docs.rs.
| Spec | What is covered |
|---|---|
| 2.1 | vCard 2.1: the original versit format, including its quoted-printable and charset conventions |
| 2425 | text/directory: bare directory records carrying no BEGIN and END envelope |
| 2426 | vCard 3.0 |
| 6350 | vCard 4.0: the current standard, with its full property set, value types and parameters |
| 7095 | jCard: the JSON representation of a card |
| 9553 | JSContact: the Card object model exchanged over JMAP |
| 9554 | vCard format extensions: the newer properties and the extended address components, modeled first-class |
| 9555 | JSContact vCard mapping: the lossless conversion between a card and a JSContact Card |
The whole API is documented on docs.rs, from parsing and byte-faithful editing to the strict builder, validation and the optional jCard and JSContact codecs.
Complete runnable programs live in ./examples; the tests also demonstrate real usage.
This project is developed with AI assistance. This section documents how, so users and downstream packagers can make informed decisions.
- Tools: Claude Code (Anthropic), invoked locally with a persistent project-scoped memory and a small set of repo-specific rules.
- Used for: Refactors, mechanical multi-file edits, boilerplate (feature gates, error enums, derive macros, trait impls), test scaffolding, doc polish, exploratory design conversations.
- Not used for: Engineering, critical code, git manipulation (commit, merge, rebase…), real-world tests.
- Verification: Every AI-assisted change is read, compiled, tested, and formatted before commit. Behavioural correctness is verified against the relevant RFC or upstream spec, not assumed from the model output. Tests are never adjusted to fit AI-generated code; the code is adjusted to fit correct behaviour.
- Limitations: AI models occasionally produce code that compiles and passes tests but is subtly wrong. The verification workflow catches most of this; it does not catch all of it. Bug reports are welcome and taken seriously.
- Last reviewed: 08/08/2026
This project is licensed under either of:
at your option.
- Chat on Matrix
- News on Mastodon or RSS
- Mail at pimalaya.org@posteo.net
Contributions are welcome: start with CONTRIBUTING.md, which opens with the Pimalaya-wide guides to read first.
Special thanks to the NLnet foundation and the European Commission that have been financially supporting the project for years:
- 2022 → 2023: NGI Assure
- 2023 → 2024: NGI Zero Entrust
- 2024 → 2026: NGI Zero Core
- 2027 in preparation…
If you appreciate the project, feel free to donate using one of the following providers:
