Encoding functions — Marketing Cloud SSJS reference | Cleon

Encoding shows up everywhere SSJS interacts with the outside world: Authorization: Basic headers for API callouts, query parameters carrying user identifiers through CloudPage URLs, signed payloads handed to webhooks, opaque tokens stored in DEs. Marketing Cloud exposes the four operations you need (Base64Encode, Base64Decode, URLEncode, URLDecode) directly under Platform.Function. The traps are about which encoding to use where, and what happens when a string survives one round-trip but not the next.

Official syntax

Platform.Load("Core", "1.1.5");

// === BASE64 ===

// Encode a string to Base64
var b64 = Platform.Function.Base64Encode("hello world");
// → "aGVsbG8gd29ybGQ="

// Decode Base64 back to a string
var raw = Platform.Function.Base64Decode("aGVsbG8gd29ybGQ=");
// → "hello world"

// Common pattern: HTTP Basic Auth header
var auth = "Basic " + Platform.Function.Base64Encode("clientId:clientSecret");
// → "Basic Y2xpZW50SWQ6Y2xpZW50U2VjcmV0"

// === URL ENCODING ===

// Encode a value safely for use in a URL
var encoded = Platform.Function.URLEncode("user+name@example.com&id=12");
// → "user%2Bname%40example.com%26id%3D12"

// Decode a URL-encoded value back to its original form
var decoded = Platform.Function.URLDecode("user%2Bname%40example.com");
// → "user+name@example.com"

// Common pattern: building a redirect URL with user-supplied params
var redirect = "https://app.example.com/preferences?email="
  + Platform.Function.URLEncode(emailAddress)
  + "&token=" + Platform.Function.URLEncode(token);

// === GUID-to-Base64 (some tenants) ===

// Convert a GUID to a compact Base64 representation
var compactId = Platform.Function.GuidToBase64(Platform.Function.GUID());
// → e.g. "Ks1L7Z+Y0E6XbDtF8H3iAg=="

The supported set:

| Function | Input | Output | Use for | |---|---|---|---| | Base64Encode(s) | String | Base64 string | Auth headers, opaque tokens, binary-as-text | | Base64Decode(s) | Base64 string | String | Inverse of Base64Encode | | URLEncode(s) | String | Percent-encoded string | URL query params, redirect URLs | | URLDecode(s) | Percent-encoded string | String | Inverse of URLEncode | | GuidToBase64(guid) | GUID string | Compact Base64 string | Shortened identifiers in URLs / DEs |

Reference:

What survives in production

Base64 vs URL encoding — they're not interchangeable

This is the conceptual mistake that ships to production most often. Base64 and URL encoding solve different problems and are not safe substitutes for each other.

Base64 turns arbitrary bytes into an ASCII alphabet (A-Z, a-z, 0-9, +, /, =). It does not make a string URL-safe — + and / and = all have special meaning in URL query strings.
URL encoding (a.k.a. percent-encoding) turns characters that have meaning in URLs (&, =, +, ?, /, etc.) into %XX escape sequences. It does not turn binary into text — it assumes the input is already a printable string.

// AT RISK — Base64 in a URL without further encoding
var token = Platform.Function.Base64Encode("clientId:secret");
// → "Y2xpZW50SWQ6c2VjcmV0"  (no special chars in this case, lucky)

var url = "https://api.example.com/?token=" + token;
// Works for THIS specific input, fails the moment encoded output contains "+", "/", or "="

// SAFE — Base64-then-URLEncode for tokens going into URLs
var token = Platform.Function.URLEncode(
  Platform.Function.Base64Encode("clientId:secret")
);
var url = "https://api.example.com/?token=" + token;

The general rule: if it's going into an HTTP header, Base64 alone. If it's going into a URL query string, URL-encode whatever you put there — even if it's already Base64.

Round-trip Base64 isn't always lossless on whitespace + line endings

Base64 is officially padded with = at the end and may include line breaks every 76 characters in some implementations. SFMC's Base64Encode produces a clean unpadded-or-padded line without breaks; some external systems produce broken-line output that SFMC's Base64Decode may handle, may not. The safe assumption: when receiving Base64 from external sources, sanitize whitespace before decoding.

// AT RISK — external Base64 with line breaks may decode to garbage on some tenants
var raw = Platform.Function.Base64Decode(externalToken);

// SAFE — strip whitespace before decoding
var sanitized = String(externalToken).replace(/\s+/g, "");
var raw = Platform.Function.Base64Decode(sanitized);

The same applies to padding: some sources omit the trailing = characters. SFMC's decoder is generally lenient, but if you see "Invalid Base64 string" errors on otherwise valid input, padding is the first thing to check.

`URLEncode` doesn't encode the entire URL — only the value

A common bug: passing the entire URL to URLEncode. The result encodes the :// and the slashes and produces nonsense.

// BUG — encodes the entire URL, including the parts that should NOT be encoded
var url = Platform.Function.URLEncode("https://api.example.com/?id=12");
// → "https%3A%2F%2Fapi.example.com%2F%3Fid%3D12"
// Useless as a URL — won't navigate, won't fetch

// CORRECT — encode only the values, build the URL around them
var id = "12";
var url = "https://api.example.com/?id=" + Platform.Function.URLEncode(id);
// → "https://api.example.com/?id=12"

// Multiple params
var url = "https://api.example.com/?email=" + Platform.Function.URLEncode(email)
        + "&id=" + Platform.Function.URLEncode(id)
        + "&action=" + Platform.Function.URLEncode(action);

The mental model: URLEncode is for values, not for URLs.

URL-encode user-supplied values before concatenation

Skipping URLEncode on user input is a XSS / link-injection vector, not just a correctness issue. A malicious value containing &action=delete could change the meaning of the URL if pasted in raw.

// AT RISK — user-supplied 'next' parameter pasted raw
var next = Request.GetQueryStringParameter("next");
var redirect = "/done?next=" + next;
// If next is "anything&injected=value", you've added an injected param

// SAFE — encode the value
var redirect = "/done?next=" + Platform.Function.URLEncode(next);

Even when the value comes from a trusted source (a DE field you wrote yourself), URL-encode it on the way out. The cost is one function call per value; the saving is not having to audit every code path that produced the value.

Quick decision

Use Base64Encode when:

Building an HTTP Authorization: Basic header (the canonical use).
Storing or transmitting an opaque token where the receiver also speaks Base64.
Reducing a multi-line string to one line for storage in a single DE field.

Use URLEncode when:

Putting any value into a URL query string. Always.
Building redirect URLs with user-supplied parameters.
Constructing hyperlinks programmatically in CloudPage SSJS or email content.

Combine Base64Encode then URLEncode when:

A Base64 token has to travel through a URL. The order matters — encode to Base64 first, then URL-encode the result.

Use GuidToBase64 when:

You want a compact identifier (22 chars vs 36 for a hyphenated GUID) for URLs or storage. Reverse with Base64ToGuid if available on your tenant.

Don't reach for these when:

The value is already in the right encoding for its destination. Double-encoding produces escape-sequence soup that no one decodes correctly.

Basics — supported language surface
Platform.Function — the namespace where these helpers live
String functions — for stringification before encoding
WSProxy — auth tokens often involve Base64 (e.g., for Basic auth on legacy SOAP integrations)
MC SSJS gotchas — see #9 (HTTP callouts) for the broader auth-and-encoding context

More SSJS reference pages incoming: Hashing · Util / Variable · Style Guide.

Plus how-to snippets for common production patterns — DE add/update/upsert, error handling, callout pagination, etc.