V2Ray Subscription Formats: Base64, Native JSON, and Share Link Conversion

1. Subscription URLs, Base64, and JSON are different layers

“V2Ray subscription” isn’t a single format defined by a file extension. Typically, a client requests a URL over HTTPS, receives text, parses the nodes in it, and adds them to its configuration list. The URL is used to fetch and update content; the response body determines how that content is parsed. So a missing file extension—or a .txt suffix—doesn’t tell you whether it can be imported.

Base64 does not provide encryption. Subscription tokens and node credentials can still be recovered even when they appear as a long string of characters. Don’t submit full subscription content to public conversion sites, and hide query parameters in URLs when sharing screenshots for support.

2. How vmess:// and vless:// links differ

A common VMess share link consists of vmess:// followed by a Base64-encoded JSON object. The object often contains fields such as add, port, id, net, and tls. It describes a node in a share-link format; it is not a complete configuration you can pass directly to Xray to start it.

A VLESS link usually isn’t “the entire link encoded in Base64 again.” Its parameters may also include flow, fp, pbk, and sid, covering flow control, fingerprinting, and REALITY settings. The exact parameter names and supported values depend on the client version; the protocol prefix alone doesn’t guarantee that every parameter is supported.

• Port: A remote port of 443 doesn’t necessarily mean TLS is enabled. Check the security settings too.
• Path: A WebSocket path containing / may appear as %2F. Decode it according to URI rules; don’t simply remove the percent sign.
• Domain: The server address, TLS SNI, and WebSocket Host are separate fields. Use the same value only if that’s what the server requires.
• Line breaks: A node list usually has one link per line. A hard line break inserted by a messaging app may truncate query parameters.

3. Decoding Base64 subscriptions—and why some need two decoding steps

Suppose the response body is multiple VMess links joined as text and then Base64-encoded as a whole. The first decode reveals the links, one per line. The payload after each vmess:// still needs to be decoded separately to reveal the node fields. These are two nested encoding layers; not every subscription needs to be decoded twice.

1. Check the raw content first. If each line already starts with vmess:// or vless://, there’s no need to decode the whole response.
2. If the content looks like Base64, try decoding it once and check whether the result is a list of links.
3. If decoding reveals HTML, a sign-in prompt, or an error message, fix the retrieval issue first and stop converting formats.
4. If the result is JSON, inspect its structure. A JSON array, a core configuration, and an API response aren’t interchangeable just because they’re all valid JSON.

The native JavaScript function below processes text offline; it only encodes and decodes and makes no network requests. It supports common Base64URL characters and uses UTF-8 for Chinese labels. Use it in a trusted local environment, and don’t paste real subscription content into the console on an unfamiliar website.

function decodeBase64Text(source) {
  const normalized = source.trim()
    .replace(/\s+/g, "")
    .replace(/-/g, "+")
    .replace(/_/g, "/");
  const padded = normalized.padEnd(
    Math.ceil(normalized.length / 4) * 4, "="
  );
  const bytes = Uint8Array.from(
    atob(padded), char => char.charCodeAt(0)
  );
  return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
}

function encodeBase64Text(text) {
  const bytes = new TextEncoder().encode(text);
  let binary = "";
  for (const byte of bytes) {
    binary += String.fromCharCode(byte);
  }
  return btoa(binary);
}

4. Where to import in v2rayN and v2rayNG

GUI clients typically manage server nodes, subscription groups, and custom full configurations separately. Node importers recognize share links; subscription settings store update URLs; custom configuration options handle full JSON files. Don’t paste all three kinds of content into the subscription URL field.

v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. A JSON config that works in v2rayNG won’t necessarily work unchanged in v2flyNG. Check compatibility with the target core, especially for REALITY, specific transport settings, and core-specific fields.

5. Converting between formats—and what doesn’t carry over

Converting between share links and Base64 subscriptions usually changes only the outer wrapper: join complete links with line breaks, then encode the text as UTF-8 Base64 to create a typical static subscription body. But the body alone isn’t an updatable subscription service; the client still needs a URL to fetch it and a mechanism to maintain its content.

When converting JSON, don’t just extract the server, port, and identity fields. For WebSocket over TLS, also check the transport type, path, Host, TLS setting, and SNI. For VLESS with REALITY, check the public key, short ID, and related flow-control settings. If anything is missing, the client may report a successful import while the connection still fails.

1. Check the input structure first: VMess JSON in a share link and an object in the core’s outbounds use different fields.
2. Choose the target next: If the full configuration has multiple remote outbounds, decide which one to export. Don’t mistake a direct or blocked outbound for a node.
3. Compare settings individually: After importing into the target client, open the edit screen and check the security, transport path, and protocol-specific fields.
4. Test last: First confirm the core starts, then test a request. A working node doesn’t mean the original routing behavior has been restored.

6. Subscription and conversion FAQs

A reliable workflow is to identify what you received, choose the matching import option, then check the protocol settings and core logs. Treat retrieval failures, format mismatches, and connection configuration errors as separate issues; that’s more effective than repeatedly changing the encoding.