Subscription Formats Explained: Base64, Native JSON, and Share Links

Each format solves a different problem

“Subscription” is often used as a broad term, but the data you receive may belong to one of three layers. A Base64 bundle wraps multiple share links; a VMess or VLESS share link usually describes one outbound node; native JSON can define a complete runtime config with inbounds, outbounds, DNS, logs, and routing rules. Identify the layer first, then choose the import method instead of trying buttons at random.

Seeing a long string of letters, numbers, and a few equals signs after opening a subscription URL in a browser does not mean the content is broken. It may be an entire text response encoded with Base64. If decoding produces lines beginning with vmess:// or vless://, it is a typical bundled subscription. Here, encoding only packages the text; it is not encryption and does not change the node parameters.

Inside a Base64 subscription bundle

A typical bundled subscription returns a Base64-encoded text response. After decoding, it usually contains UTF-8 text with one share link per line; line endings may be LF or CRLF. When updating, the client requests the URL, decodes the text, and parses each line according to its protocol prefix. Unrecognized lines are usually skipped, so “update succeeded but zero nodes appeared” often means the decoded protocol is unsupported by the current client, or the server returned a login page, notice, or other non-subscription content.

dmxlc3M6Ly9mNDdhZDQ4YS1hZWMxLTQwZTQtYTgzOC0wNjE2N2VhZDc4OTVA
ZXhhbXBsZS5pbnZhbGlkOjQ0Mz9lbmNyeXB0aW9uPW5vbmUmc2VjdXJpdHk9
dGxzJnR5cGU9d3MmcGF0aD0lMkZhcGkjVExTLVdTLUV4YW1wbGU=

The content above is only a format illustration. To check whether something is Base64, first see whether its characters are mostly within A-Z, a-z, 0-9, plus, slash, and equals signs, then decode it. Character appearance alone cannot prove validity, because ordinary random text may fit the same range. A better test is whether decoding produces readable text and whether each line begins with a supported protocol prefix.

A VMess share link itself often contains a layer of Base64 encoding. Its payload is generally a JSON object describing the address, port, user ID, transport, and TLS parameters. A VMess bundled subscription may therefore encode the single-node JSON into a vmess:// link, concatenate multiple links, and encode the complete bundle again. Troubleshoot one layer at a time; do not decode the entire subscription as though it were a single VMess node.

How VMess and VLESS share links describe a node

Share links are designed to let a client rebuild one outbound node. VMess commonly places a Base64-encoded JSON object after the protocol prefix; VLESS is closer to a standard URI, with the user ID in the user-info section, the server address and port in the host section, transport, security, and flow-control settings in the query string, and the text after the hash used as the node name. Both link types may contain sensitive connection credentials and should not be pasted into public pages or public logs.

1. Read the protocol prefix to determine whether to use the VMess or VLESS parser.
2. Extract the server hostname, port, and user ID, and verify that the port is an integer from 1 to 65535.
3. Read the transport type, such as TCP, WebSocket, or gRPC, and parse the path or service name accordingly.
4. Read the TLS, server name, and application-layer protocol settings instead of migrating only the address and port.
5. Decode the node remark and process percent-encoding before displaying it in the server list.

VLESS URI structure

The example below uses a reserved domain that cannot be resolved; the focus is on field placement. security=tls sets transport security, type=ws selects WebSocket, path is the request path, and sni is the server name used during the TLS handshake. Handle parameter name case sensitivity according to the client implementation, and avoid manually rewriting unknown fields.

vless://[email protected]:443?encryption=none&security=tls&sni=edge.example.invalid&type=ws&path=%2Fproxy#TLS-WS-Example

VMess and VLESS cannot be converted by simply replacing the protocol name. Their authentication models and parameter sets differ, and fields such as VLESS flow have no direct VMess equivalent. Only when the server provides both inbound configurations can it generate two separately connectable share links; rewriting the URI alone does not add support for another protocol on the server.

How native JSON relates to client subscriptions

Native JSON targets the V2Ray or Xray kernel. Common top-level fields include log, dns, inbounds, outbounds, and routing. A share link can usually map only to one outbounds entry. If the JSON also contains routing rules based on domains, IPs, ports, or inbound tags, exporting it as a single-node link cannot preserve the original behavior.

A minimal configuration is not the same as a subscription

The JSON below defines one local SOCKS inbound and one VLESS outbound. Even if the outbound fields are converted into a share link, the listening address 127.0.0.1, port 10808, and routing behavior will not be included. The target client fills them in with its defaults or existing settings.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.invalid",
            "port": 443,
            "users": [
              {
                "id": "f47ad48a-aec1-40e4-a838-06167ead7895",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    }
  ]
}

• inbounds determines how local programs hand traffic to the kernel.
• outbounds determines which remote protocol carries traffic out, or whether it connects directly.
• routing selects an outbound based on domains, IPs, ports, and tags.
• dns determines how names are resolved, but does not automatically become a node sharing parameter.

JSON exported by a client may also include generated tags, statistics policies, or kernel-specific fields. Before importing it into another client, confirm that the target client’s kernel and version recognize those fields. v2rayNG uses the Xray kernel, while v2flyNG uses the v2fly kernel; their support overlaps for basic VMess, VLESS, and common transports, but new fields and extensions should not be assumed to work identically.

Practical steps for importing, converting, and updating

For everyday use, let the client read the subscription URL directly instead of decoding it manually and importing nodes one by one. Direct subscriptions preserve the update path, so the client can fetch the list again when the provider changes node names, addresses, or ports. Manual conversion is best for inspecting content, moving a small number of nodes, or finding why a specific record failed to parse.

Menu labels may change between client versions, but the basic sequence remains the same: save the subscription URL, update it manually, then select a node and start the connection. During testing, do not rely only on an “active” status; also check core logs, actual latency, and whether the target site loads. A failed latency test does not always mean the node is unusable—the test endpoint may be unreachable or DNS resolution may be failing.

Fields to preserve and security boundaries during conversion

A reliable converter should parse the input into a structured object and serialize it again in the target format, rather than performing string search-and-replace. At minimum, preserve the protocol, server address, port, user ID, transport type, TLS state, server name, path or service name, flow-control settings, and node remark. Missing any connection-critical field can produce a record that imports successfully but cannot connect.

1. Copy the original content into a controlled local environment and determine whether it is a subscription response, share link, or complete JSON.
2. Decode and parse it into a field object, then type-check the port, user ID, and required parameters.
3. Filter fields according to the target client and kernel capabilities, and record anything that cannot be mapped.
4. After generating the target format, parse it again and compare the address, port, security layer, and transport layer.
5. Create a separate test group in the client without overwriting the original subscription that still works.
6. After connecting, check the core logs and test DNS, TCP, and any required UDP scenarios separately.

Subscription URLs and share links may directly contain access credentials. When sharing screenshots for troubleshooting, obscure the full subscription URL, user ID, and authentication fields; when sharing logs, keep only the error type, time, and necessary network status. If a subscription URL has entered a public record, replace its credentials in the provider’s dashboard, delete the old URL from clients, and perform a full update.