Clash Subscription Formats Explained: YAML, Base64 Links & Conversion

Why subscription formats differ

Clash originally recognized only one format: a complete YAML config file containing node info (proxies), policy groups (proxy-groups), and routing rules (rules) all at once. This single file is both the node list and the behavior manual — the client can load and run it directly after downloading.

But node providers don't always want to maintain a full ruleset — most subscription providers prefer to publish just the nodes, leaving rule organization to the user or the client's built-in presets. This gave rise to two lighter formats: Base64-encoded node lists and generic share-link aggregates. Each format serves a different use case, and none is strictly "better," but mixing them carelessly often causes field loss or clients that simply can't parse the content.

Full YAML config: field structure and use cases

A YAML subscription is essentially a ready-to-run config.yaml. mihomo (the Clash Meta core) extends the original syntax with new fields, but the top-level structure stays largely the same:

mixed-port: 7890
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
proxies:
  - name: "hk-01"
    type: ss
    server: example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
proxy-groups:
  - name: "Auto"
    type: url-test
    proxies:
      - hk-01
    url: "http://www.gstatic.com/generate_204"
    interval: 300
rules:
  - DOMAIN-SUFFIX,google.com,Auto
  - GEOIP,CN,DIRECT
  - MATCH,Auto

The advantage of this format is that it works out of the box: rules, policy groups, and DNS settings are all maintained by the subscription provider, so users don't need extra configuration after importing. The downside is equally clear — once a client needs to merge multiple subscriptions, or add custom routing on top of the existing rules, it becomes trickier than working with a plain node list, since fields must be merged rather than simply appended.

Also note that fields added by the mihomo core (such as the smart group type or the sniffer domain-sniffing config) are either ignored or will throw errors on the original Clash core. It's worth confirming which core your client uses before downloading a YAML subscription.

Base64 node lists vs. generic share links

If a subscription link returns not readable YAML but a long string of seemingly random characters, it's most likely a Base64-encoded node list. Each line typically represents one node, in the form protocol://encoded-connection-params, with common protocol prefixes like ss://, vmess://, trojan://, and ssr://. The entire subscription is then Base64-encoded as a whole.

ss://[email protected]:443#hk-01
vmess://eyJ2IjoiMiIsInBzIjoic2ctMDIi...
trojan://[email protected]:443?sni=example.net#sg-02

This format only describes "what the nodes are" — it contains no routing rules or policy-group info. The client's subscription parser reconstructs each line into a node object, then applies rule templates either built into the client or provided by a conversion service. Its advantage is broad compatibility — almost any client that supports proxy protocols (not just Clash) can parse it. Its downside is that without a conversion tool, dropping this kind of link straight into a Clash client that lacks auto-conversion usually loads nothing at all, since native Clash only understands YAML.

The so-called "generic share-link aggregate" is really just another name for the same Base64 node list, commonly seen on provider subscription pages. At the URL level it's often indistinguishable from a plain YAML subscription — you can only tell by inspecting the content.

Switching clients: conversion methods and tool choices

When switching clients or devices, the most common need is converting a Base64 node list into a fully usable YAML config, or the reverse — extracting node info from YAML for use elsewhere. There are three common approaches:

1. Built-in client conversion: Most Clash clients (including those supporting the mihomo core) automatically detect Base64 node lists when adding a subscription, convert them into YAML internally, and apply a default rule template — no manual work needed. This is the most hassle-free option.
2. Subscription conversion services: Submit the raw subscription link along with a rule template to a conversion service, which fetches the nodes, applies the rules, assembles a full YAML file, and returns a new subscription URL. This suits scenarios that need custom policy groups or merging multiple subscription sources.
3. Manual local conversion: For users with few nodes who want full control over their rules, you can manually decode the Base64 content and fill in the extracted node parameters into the YAML proxies field one by one, writing your own rules and policy groups. This is the most tedious option, but it doesn't depend on any third-party service.

Which method to use mainly depends on how stable the subscription source is and how often rules need adjusting. For a quick test with a different client, built-in auto-detection is fine; for a long-term subscription meant to work across multiple clients, a conversion service is more convenient.

Common field loss during conversion and how to avoid it

The trickiest issues in format conversion usually aren't nodes that fail to connect, but fields that "seem unimportant" and get silently dropped by conversion tools. The following fields are especially prone to disappearing:

• TLS-related parameters: Fields like skip-cert-verify, sni, and alpn — some simplified conversion tools don't parse these by default, causing otherwise working nodes to fail the handshake after conversion.
• Transport-layer extensions: Transport configs commonly found on VMess/Trojan nodes, such as ws-opts and grpc-opts, get skipped entirely if the conversion tool only parses the most basic protocol template.
• Policy-group references: If the original subscription's rules reference a specific custom policy-group name, and node or group names change after conversion, rules that reference the old group won't match anything and fall back to the default policy.
• DNS and TUN-related config: A plain node list doesn't carry these fields, so a conversion service fills them in with its own default template, which may not match your usual DNS setup — worth checking manually after conversion.

Also, different conversion services vary in protocol support, especially for newer protocols or obfuscation parameters. After converting, it's worth opening the generated YAML file and spot-checking a few nodes' fields for completeness, rather than just checking that the node count matches.

Format comparison summary

Overall, once you determine which category a subscription's content actually falls into, and pick the matching import or conversion method, most "no nodes after import" or "rules not working" issues can be avoided ahead of time. Format conversion isn't guesswork — it comes down to confirming whether all fields survived the process intact.