# DID Methods Compared: did:web, did:key, did:ion and More

Source: https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/
Last updated: 2026-07-06
License: content by Start with Identity. Cite the source URL.

---

The `method` in a [decentralized identifier](https://startwithidentity.com/standards/decentralized-identifiers-did/) determines how it is created and resolved, and the choice has real operational consequences. This guide compares the methods that matter in production so you can pick one without over-engineering. For the standard itself, see the [DID standard deep dive](https://startwithidentity.com/standards/decentralized-identifiers-did/) and the [DID method](https://startwithidentity.com/glossary/did-method/) glossary entry.

## Two families

DID methods split into two camps:

- **Ledgerless:** resolution uses ordinary infrastructure (DNS, HTTPS, or the identifier itself). Simple to operate, no blockchain.
- **Ledger-anchored:** resolution uses a distributed ledger, adding decentralization independent of any single domain or provider, at the cost of ledger dependency, governance, and sometimes fees.

## The methods that matter

**did:web** anchors a DID to a domain by hosting the [DID document](https://startwithidentity.com/glossary/did-document/) at a well-known HTTPS path. It reuses the TLS and DNS trust you already run, needs no ledger, and is the most common enterprise choice. The tradeoff: it inherits DNS and domain-control assumptions, so it is only as decentralized as your domain.

**did:key** encodes a public key directly in the identifier, so it is fully self-contained with no network lookup. Ideal for ephemeral or holder-side identifiers and testing. The tradeoff: no rotation or service endpoints, because there is nothing to update.

**did:jwk** is similar to did:key but wraps a JWK, convenient in JWT-heavy stacks.

**did:ion** anchors to Bitcoin via the Sidetree protocol, giving strong decentralization without per-operation on-chain cost. The tradeoff: more moving parts and reliance on the ION network.

**did:ethr** anchors to Ethereum, common in Web3-adjacent ecosystems. The tradeoff: chain dependency and gas considerations.

**did:indy** is used in Hyperledger Indy ecosystems, often paired with [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) credentials. The tradeoff: it ties you to that ecosystem's governance and ledger.

## How to choose

Work from constraints, not novelty:

1. **Do you need decentralization independent of DNS?** If no, `did:web` is almost always right.
2. **Is the identifier ephemeral or holder-side?** `did:key` fits.
3. **Are you joining an existing ecosystem** (an EU pilot, a Hyperledger network, a Web3 project)? Use the method that ecosystem standardizes on.
4. **As a verifier,** support every method your issuers use, gated by what your resolver and libraries handle.

For most organizations issuing or accepting credentials, the answer is `did:web` for issuers and whatever the wallets use for holders, with ledger methods added only when a concrete requirement demands them.

## Where to go next

Build: [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/). Overview: [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/). Vendors: [decentralized identity directory](https://startwithidentity.com/vendors/decentralized-identity/).