LDIF (LDAP Data Interchange Format) is the standard plain-text format for representing directory entries and changes. Tools like ldapadd and Active Directory's ldifde read LDIF to create users and objects in bulk, making it the usual way to import many contacts at once.

Which vCard fields are mapped?

FN becomes cn, N becomes sn and givenName, EMAIL becomes mail, TEL becomes telephoneNumber or mobile depending on the TYPE, ORG becomes o and ou, TITLE becomes title, ADR becomes street, l, st and postalCode, URL becomes labeledURI, and NOTE becomes description.

What object classes are used?

Each entry is created with top, person, organizationalPerson and inetOrgPerson, which is the standard schema for representing people in OpenLDAP and most directories. inetOrgPerson provides mail, mobile, title and the other common contact attributes.

Why are some values shown with a double colon?

LDIF requires base64 encoding for any value containing non-ASCII characters, a leading space or certain special characters. Those lines use the attr:: base64 form, which ldapadd decodes automatically, so accented names and addresses import correctly.

Is my contact data uploaded?

No. Parsing and conversion happen entirely in your browser with JavaScript. Your contacts never leave your device, so it is safe to convert a full personal or corporate address book.

vCard to LDIF Converter

This tool converts vCard contact files (.vcf) into LDIF, the text format used to bulk-import entries into an LDAP directory such as OpenLDAP or Active Directory. Instead of adding contacts one at a time, you export your address book to a single .vcf, convert it here, and feed the result to ldapadd or ldifde to create every person in one operation.

How it works

A vCard is a sequence of BEGIN:VCARD … END:VCARD blocks, each containing properties like FN, EMAIL and TEL. The converter first unfolds continuation lines (lines that begin with a space continue the previous one, per RFC 6350), then parses each property along with its parameters such as TYPE=CELL.

Each contact is then mapped to an LDIF entry under the inetOrgPerson schema:

FN becomes the cn, which also forms the entry’s relative distinguished name.
N is split into sn (family name) and givenName.
EMAIL becomes one or more mail attributes.
TEL with a CELL/MOBILE type becomes mobile, otherwise telephoneNumber.
ORG becomes o plus an ou per additional unit, TITLE becomes title.
ADR is split into street, l (locality), st (region) and postalCode.
URL becomes labeledURI and NOTE becomes description.

The distinguished name is cn=<name>,<base DN>, with RFC 4514 escaping applied to any commas or special characters in the name.

Base64 and encoding

LDIF is ASCII-oriented. Any value that contains non-ASCII characters (accented names, addresses in other scripts) or begins with a space or a reserved character must be base64-encoded. The converter detects this and emits those values using the attribute:: base64 form, which ldapadd decodes back to the original UTF-8 automatically.

Tips and example

Set the base DN to match your directory layout, for example ou=people,dc=example,dc=com. After downloading the file, import it with:

ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f contacts.ldif

Review the generated cn values first — if two contacts share the same full name they will produce the same DN, so make those names unique before importing to avoid a duplicate-entry error.