Subscription link formats: base64, native JSON, and share links compared and converted

When adding a server in v2rayN, v2rayNG, or v2flyNG, you may receive a subscription URL beginning with https://, an apparently unstructured string of base64 text, or a single-node share link beginning with vmess:// or vless://. All can carry connection details, but their update methods, portability, and import paths differ.

First identify whether you have a subscription URL, encoded content, or a share link

“Subscription link” is often used as a broad term. Strictly speaking, a subscription URL is a network endpoint that can be requested repeatedly; the client accesses it to retrieve a node list. base64 is a common encoding wrapper used for the returned list, while a share link usually describes only one node. Native JSON is closer to a complete configuration file or structured API response and is not automatically an updateable subscription.

The quickest way to identify the format is to inspect the beginning. Content starting with https:// and containing a relatively long path is usually a remote subscription URL. Long text made up of letters, digits, plus signs, slashes, or underscores may be base64 or URL-safe base64. Content beginning with vmess:// or vless:// is a protocol share link. Content beginning with an opening brace and containing paired field names is usually JSON.

How to decode and inspect a base64 subscription

base64 is an encoding method, not an encryption protocol. It converts raw bytes into characters that are easier to transmit as text, so a long block of unreadable text does not mean the content is protected. A common V2Ray subscription first joins multiple share links with line breaks, then base64-encodes the complete text. After decoding, you will often see one vmess:// or vless:// URL per line.

Standard base64 commonly uses upper- and lowercase letters, digits, +, /, and the padding character = at the end. The URL-safe variant replaces + with - and / with _, and may omit trailing padding. Clients usually support both variants, but manual inspection requires restoring the characters and padding first.

1. Confirm that the current content is the body returned by the server, not a remote URL that still begins with https://.
2. Remove spaces and leading or trailing line breaks introduced during copying, but do not delete valid characters that may occur inside the content.
3. Convert URL-safe base64 - and _ back to the standard characters, then pad the length to a multiple of 4.
4. After decoding, check that every line has a recognizable protocol prefix, node names are not garbled, and ports fall within the range 1–65535.
5. If the decoded result is still base64 text, determine whether it is the second encoding layer inside a VMess share link. Do not decode repeatedly without checking.

The browser-console code below processes text only on the current device. After running it, a prompt appears and the decoded result is printed to the console. Subscription content often contains server addresses, user identifiers, and transport parameters, so avoid submitting real data to unknown online conversion pages.

const encoded = prompt("Paste the base64 subscription content").trim();
const normalized = encoded.replace(/-/g, "+").replace(/_/g, "/");
const padded = normalized.padEnd(
  Math.ceil(normalized.length / 4) * 4,
  "="
);
const bytes = Uint8Array.from(
  atob(padded),
  character => character.charCodeAt(0)
);
console.log(new TextDecoder().decode(bytes));

Key fields in native JSON configuration

Native JSON used by the V2Ray or Xray core is a configuration tree, not just a server address. A runnable configuration typically includes local inbounds and remote outbounds; it may also add routing, dns, log, and policy fields. A subscription service may instead return a custom JSON node array with entirely different field names. The client must explicitly support that format; JSON alone does not make it a core configuration.

The following VLESS and WebSocket example illustrates the configuration hierarchy. The example domain is for documentation only; focus on how protocol parameters in outbounds are separated from transport parameters in streamSettings.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "edge.example.net",
            "port": 443,
            "users": [
              {
                "id": "d342d11e-d424-4583-b36e-524ab1f0afa4",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/gateway"
        },
        "tlsSettings": {
          "serverName": "edge.example.net"
        }
      }
    }
  ]
}

• address should contain only the hostname; the WebSocket path belongs separately in wsSettings.path.
• For a VLESS user entry, encryption is usually none. Whether TLS is enabled at the transport layer is determined by streamSettings.security.
• The local SOCKS inbound listens on 127.0.0.1, meaning it accepts connections only from the same device. LAN sharing requires a separate review of the listen address and access controls.
• A complete configuration may also include multiple outbounds for direct connections, blocking, and other actions, linked to routing rules through tag.

Internal differences between VMess and VLESS share links

A VMess share link commonly consists of vmess:// followed by base64 content. Decoding usually produces a JSON object that may contain the address, port, user identifier, transport type, TLS status, WebSocket path, and node remark. This JSON describes a single-node share format, not a complete core configuration, because it usually lacks local inbounds, DNS, routing, and other sections.

A VLESS share link is closer to a standard URI: the user identifier appears before @, the server and port follow it, transport, security, server-name, and path parameters appear in the query string, and the node name follows #. A simplified structure looks like this.

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

d342d11e-d424-4583-b36e-524ab1f0afa4

User identifier; preserve all characters and hyphens when importing.

edge.example.net:443

Server address and port, with a standard colon before the port.

security=tls

Transport security parameters; they do not change the protocol field itself.

type=ws

Uses WebSocket transport and must match the server-side configuration.

path=%2Fgateway

A URL-encoded path that decodes to /gateway.

#Example-WS

The name shown by the client; it is not used for server authentication.

How to convert between the three formats without losing parameters

The most common conversion is from “subscription content to a list of share links.” If the remote response is base64, decode it as UTF-8 first, then split it by line breaks; each resulting line is usually an importable share link. To reverse the process, join multiple share links with line breaks and base64-encode the complete text. This changes only the wrapper and does not give static text remote update capability.

“Share link to native JSON” requires field mapping. For VLESS, the user identifier in the URI goes into settings.vnext[].users[].id, while the host and port go into address and port. The query parameter type maps to streamSettings.network, security maps to the transport security layer, and sni and the path go into their respective transport settings. You must then add local inbounds and the required outbounds to create a runnable configuration.

1. Back up the original content first, distinguishing the remote URL, response body, and single-node links.
2. List the fields that must be preserved: protocol, server, port, user identifier, transport, security layer, server name, path, and remark.
3. After decoding or converting the structure, compare the fields one by one instead of checking only whether the node name appears.
4. Import one node first to test the logs and connection, then process the remaining nodes in batches.
5. Confirm that the client still stores the original https:// URL for the subscription, then run one manual update.

Import correctly in v2rayN, v2rayNG, and v2flyNG

In v2rayN 7.x, the subscription entry is usually under “Subscription Groups” → “Subscription Group Settings.” When adding a group, enter the remote URL, save it, then use “Subscription Groups” → “Update All Subscriptions” to fetch nodes. For a single-node share link, copy it to the clipboard and use the relevant server-import option. Menu wording may vary slightly between minor releases, but “Subscription Groups” and “Server Import” are separate paths.

If system applications have no traffic after connecting, open “Settings” → “Parameter Settings” and check the local ports. Common configurations use SOCKS port 10808 and HTTP port 10809, but the current settings page is authoritative. If another program is using a port, core logs usually report a listen failure. Choose an available port and update the browser or system proxy settings accordingly.

• v2rayN: Best for desktop subscription groups, bulk node management, and custom routing. After importing, update the subscription, select an active server, and then set the system proxy mode.
• v2rayNG: Uses the Xray core on Android and is suitable for importing VMess and VLESS share links as well as remote subscriptions. After updating, confirm that the selected node still exists.
• v2flyNG: Uses the v2fly core on Android and is suitable for environments centered on VMess and other compatible configurations. For extended parameters, first confirm that the core recognizes the relevant fields.

A fixed order for subscription maintenance and troubleshooting

Format and network problems are easy to confuse. A subscription request timeout occurs while “fetching content”; invalid base64 characters or incorrect JSON fields occur while “parsing content”; a node connection timeout occurs while “using the configuration.” Check logs by stage to avoid repeatedly changing the format when the network is unreachable or blindly changing local proxy ports when the parameters are wrong.

Keep the remote subscription URL, the most recent successful update time, and the client version. When a node fails, update manually first, test one known-good node, and then inspect the core logs. In v2rayN, check the subscription-group status and log panel together; on Android, verify whether the active configuration was switched or removed after the update.

1. Fetch stage: Check the subscription domain, HTTPS connection, and response status to confirm that the client actually received the content.
2. Parse stage: Determine whether the content is base64, JSON, or a list of share links, then check line breaks, padding, and character encoding.
3. Import stage: Confirm that the client added the nodes and that the node count and group name match expectations.
4. Connection stage: Check the address, port, user identifier, transport, security layer, server name, and path.
5. Proxy stage: Check the active server, system proxy mode, and whether local ports such as 10808 and 10809 are listening normally.
6. Routing stage: When the connection works but a specific domain behaves unexpectedly, check the order of routing.rules and the outbound tags.