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

These three formats represent different configuration layers

“Subscription” is often used as a catch-all term for configuration files, but strictly speaking, a subscription is a bulk distribution mechanism, a share link is a portable representation of one node, and native JSON is the complete configuration read by the core at runtime. They may contain overlapping fields, but file extensions alone cannot establish equivalence.

A common base64 subscription response first lists multiple VMess, VLESS, and other share links line by line, then encodes the entire UTF-8 text as base64. When updating a subscription, the client downloads the response, decodes it, and parses the nodes line by line. Base64 changes only how text is represented; it does not encrypt the data or fill in missing protocol fields.

A VMess share link often contains base64 as well. In the classic format, an encoded JSON object follows vmess://; it may include the address, port, user ID, transport, TLS settings, and remark. This base64 applies only to one node object and is a different layer from the outer base64 used to encode an entire subscription.

VLESS share links usually express configuration directly through URI query parameters, such as the server address, port, encryption marker, transport type, TLS, or REALITY settings. The key-value structure is more readable, but special characters in paths, hostnames, and remarks must be URL-encoded.

How to identify base64, share links, and JSON

When identifying a format, inspect the first layer before and after decoding instead of relying on the filename. A subscription endpoint ending in .txt may still return base64, while a URL without an extension may return line-by-line share links. Confirm that the response is text, then check its protocol prefixes, JSON structure, and line breaks.

1. Check the plain-text prefix first. If it starts with vmess:// or vless://, it can usually be handled as a single-node share link.
2. Then inspect the top-level JSON fields. The presence of inbounds, outbounds, routing, and dns indicates a native configuration for the Xray or V2Fly core.
3. Check whether the text can be decoded. If it consists mainly of letters, numbers, plus signs, slashes, and trailing equals signs, try standard base64 decoding and then check whether the result contains one link per line.
4. Make sure the response is not wrapped in a webpage. If it begins with <html, an error message, or a login page, the downloaded content is not importable subscription data.

The decoded result may look like the line-by-line structure below. The example domain and user ID only illustrate field placement and cannot be used for connections.

vless://[email protected]:443?encryption=none&security=tls&type=ws&host=edge.example.com&path=%2Fws#Example-VLESS
vmess://eyJ2IjoiMiIsInBzIjoiRXhhbXBsZS1WTWVzcyIsImFkZCI6Im5vZGUuZXhhbXBsZS5jb20iLCJwb3J0IjoiNDQzIn0=

The first line is a readable VLESS URI. Before the question mark are the user ID, server, and port; after it are the transport and security parameters; after the hash is the node remark. The second line contains VMess data that must be decoded once more. This illustrates how outer subscription encoding and inner node encoding can be layered.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443
          }
        ]
      }
    }
  ]
}

This JSON already contains separate local inbound and remote outbound layers, so it should not be parsed line by line as an ordinary subscription. A complete runnable configuration also needs valid user parameters and matching transport settings; the example shows structure identification only.

Import differences between v2rayN, v2rayNG, and v2flyNG

Protocol support and text-format recognition are separate questions. A client may decode a subscription successfully but fail to connect because its current core does not support the transport or security features used by a node. Troubleshooting should verify both “parsed successfully” and “supported by the core.”

In the v2rayN 7.x interface, bulk subscriptions are usually added through “Subscription Groups” → “Subscription Group Settings.” Save the URL, return to the main window, and update the subscription. For a single share link, copy it first and use the clipboard import function. After importing, verify the address, port, transport type, TLS, SNI, and path instead of checking only the node name.

v2rayNG uses the Xray core and is suitable for importing VMess, VLESS, and related transport configurations supported by that core. The usual path is to open Subscription Group Settings, add the subscription URL, and update it; for a single link, use the add entry in the upper-right corner to import it from the clipboard. Menu labels may vary slightly between v2rayNG 1.9.x patch versions, but subscription groups and clipboard import remain separate entry points.

v2flyNG uses the V2Fly core, so prioritize configurations explicitly marked as V2Fly-compatible by the server. If a subscription includes fields implemented only by another core, the links may be read successfully but still fail at connection time with unsupported transport or security parameters. Changing the node remark or deleting unknown fields cannot establish protocol compatibility.

Practical conversion paths and information loss

First distinguish between “encoding conversion” and “protocol conversion.” Decoding base64 into line-by-line share links only restores the text; it does not change the node protocol. Rewriting VLESS as VMess involves server-side authentication and protocol implementation, so it cannot be done by replacing the link prefix.

Converting a base64 subscription into a plain-text link list is usually reversible: decode it as UTF-8, preserve each line, and encode it again in the original order. Note that standard base64 and its URL-safe variant handle characters differently; incorrectly removing trailing padding can make decoding fail.

1. Base64 subscription to a share-link list: Decode the outer text, normalize line endings, remove blank lines, and identify the protocol prefix on each line. This process generally preserves node fields.
2. Importing share links into a client: The client parses each node’s parameters and generates the corresponding outbound configuration locally. The client’s own DNS, routing, and logging settings do not come from the share link.
3. Share link to native JSON: You can generate an outbound object, but you still need to add local inbounds, DNS, routing, logging, and policies before it can become a complete runnable configuration.
4. Native JSON to share links: This works only for a clearly defined single outbound. Multiple outbounds, load balancing, routing rules, DNS servers, and policy objects cannot fit completely into one ordinary link.
5. VMess and VLESS conversion: The corresponding links can be generated only when the server provides listening and authentication parameters for both protocols. A client cannot derive one protocol’s configuration from the other on its own.

When converting a VLESS URI, preserve the case and value of every query parameter. For example, type=ws, security=tls, sni=edge.example.com, and path=%2Fws describe the transport, security layer, server name, and path respectively. Omitting any critical field may result in a failed handshake or no traffic after connection.

VMess link JSON fields have appeared in several historical forms; the port may be represented as a string or parsed as a number. Output the structure accepted by the target client rather than mechanically concatenating fields by name. If import succeeds but node parameters are empty, decode the link again and check the address, port, user ID, transport type, and TLS fields one by one.

Common subscription conversion problems

A failed subscription update is not necessarily a format problem. Network timeouts, a URL returning a login page, truncated responses, character-encoding errors, and incompatible client cores can all produce similar messages. The most effective troubleshooting sequence is to verify the raw downloaded content first, then move on to node parsing and connection tests.

If a subscription update times out, first connect through a confirmed working node, then check whether update requests are allowed through the current proxy. In v2rayN, also check whether local listening ports are already in use. Common configurations use 10808 for SOCKS and 10809 for HTTP, but the actual values are defined under “Settings” → “Parameter Settings.”

• The response begins with HTML tags: check whether the subscription URL redirects to a login or error page.
• Base64 decoding fails: check whether the copied text is missing trailing characters or the response was truncated.
• The address is empty after importing a node: check whether the inner VMess JSON fields are complete.
• The handshake fails after importing VLESS: verify the port, SNI, transport type, path, and security parameters.
• Duplicate nodes appear after updating: check whether multiple subscription groups reference the same data source and review the remark deduplication settings.

Build a maintainable subscription and configuration migration workflow

A reliable migration workflow preserves three types of information: the original subscription URL, the decoded node list, and the client’s local settings. The URL handles future updates, the node list helps locate parsing problems, and local settings cover the system proxy, DNS, routing rules, and ports that do not migrate with a share link.

Before switching clients or cores, record the protocol, server port, transport type, and security parameters of a currently working node, then import the same subscription into the target client. After updating, do not modify every node at once. Test one VMess or VLESS node for latency and connectivity first, and confirm the logs show no protocol-field errors.

1. Record the subscription group, update method, and the most recent successful update time.
2. Extract one known-working link and verify its protocol, address, port, user ID, and transport parameters.
3. Add the subscription in the target client without overwriting existing working groups.
4. Run one manual update and record the node count before and after it.
5. Test a single node and check the core logs, DNS resolution, and local listening ports.
6. Once the connection works, restore routing rules, automatic updates, and system proxy settings.

If you only need to sync nodes between v2rayN and v2rayNG, keep the subscription URL rather than repeatedly exporting complete JSON. For setups that depend on complex domain routing, multiple outbounds, and custom DNS, migrate nodes and routing in separate steps to avoid assuming that a share link contains the full behavior.

The final test is not whether a file can be “imported,” but whether all fields were parsed, the current core supports them, the connection logs are clean, and the local proxy and routing work as expected. Identify the data layer first, then choose the matching import path to avoid most subscription conversion problems.