Browser Fingerprint Spoofing in alterself Selfbots

Discord’s backend cross-references dozens of signals: user-agent strings, locale, timezone, installation UUIDs, client build numbers, and more, to distinguish legitimate browser sessions from automated ones. alterself’s SpoofEngine generates a self-consistent fingerprint for every token and injects it into every gateway connection and HTTP request automatically. You rarely need to touch it directly, but understanding how it works helps you debug unexpected authentication failures and tailor the fingerprint when needed.

How Identity Is Seeded

Rather than generating a random fingerprint on every run, SpoofEngine derives its values deterministically from a hash of your token. This seeded approach means the same token always produces the same locale, timezone, and installation UUIDs, making your sessions look like a stable, returning browser to Discord’s systems.

Token hash

When you call alterself.Client(token=...), the engine MD5-hashes your token and uses the digest as the seed for an internal RNG.

Profile generation

The seeded RNG picks a consistent locale (e.g. en-US), timezone (e.g. America/New_York), and a set of stable UUIDs for the installation and session identifiers.

READY rotation

When Discord dispatches the READY event, the engine rotates the session-level UUIDs while keeping the token-bound values (locale, timezone, installation ID) stable, matching how a real browser behaves across page refreshes.

The same token always produces the same fingerprint across restarts. If you switch tokens, you get a completely different but equally stable fingerprint for that token.

Chrome Version Resolution

alterself needs a realistic Chrome version string for the User-Agent header and X-Super-Properties. It resolves the version through a layered strategy:

Live fetch: queries Google’s versionhistory.googleapis.com API for the latest stable Chrome release.
Disk cache: if the API is unreachable, reads a previously cached version from disk.
Hardcoded fallback: if both of the above fail, uses "136" as a safe default.

This means your bot always presents a plausible, up-to-date Chrome version without requiring you to maintain it manually.

Build Number Resolution

Discord’s X-Super-Properties header must contain the correct client build number or the gateway will reject the connection. alterself resolves it through its own layered strategy:

Live scrape: fetches Discord’s login page and extracts the build number from the bundled JavaScript.
Memory cache: caches the scraped value in memory for one hour to avoid repeated scrapes.
Disk cache: persists the value to disk so it survives restarts.
Hardcoded fallback: if all of the above fail, uses 612808.

Manual Build Refresh

If you suspect the cached build number is stale (for example, after a Discord client update), you can force a fresh scrape:

bot._spoof.refresh_build()

Call this before bot.run() or inside an on_ready handler. The engine will scrape Discord’s login page immediately and update both the memory and disk caches.

X-Super-Properties

Every HTTP request and the gateway IDENTIFY payload includes an X-Super-Properties header. Discord uses it to verify that your client looks like a real browser. alterself constructs it automatically from the generated profile. The header is a base-64-encoded JSON object containing fields such as:

Field	Description
`os`	Operating system (e.g. `"Windows"`)
`browser`	Always `"Chrome"`
`device`	Empty string (desktop)
`system_locale`	Locale derived from token seed (e.g. `"en-US"`)
`has_client_mods`	Always `false`
`browser_user_agent`	Full Chrome UA string
`browser_version`	Resolved Chrome version
`os_version`	Windows build string
`referrer`	Simulated referrer URL
`referring_domain`	Simulated referring domain
`referrer_current`	Current-page referrer
`referring_domain_current`	Current-page referring domain
`release_channel`	`"stable"`
`client_build_number`	Resolved Discord build number
`client_event_source`	`null`
`client_launch_id`	Per-launch identifier UUID
`launch_signature`	Signature tied to the launch
`client_app_state`	`"focused"` or `"unfocused"`
`client_heartbeat_session_id`	Session-level heartbeat UUID

You never need to set these fields manually. The engine serialises and encodes the header for every request.

App State Tracking

Discord expects the client to report whether its window is currently focused. alterself tracks this with set_state(), which updates the client_app_state field sent in presence updates.

bot._spoof.set_state(focused=True)   # client_app_state = "focused"
bot._spoof.set_state(focused=False)  # client_app_state = "unfocused"

You might call this inside a command handler to simulate the user switching away from Discord while a long task runs.

Spoof Info Command

This command prints the active fingerprint at runtime. It is useful for verifying that the engine is working correctly or for debugging authentication errors.

@bot.command(aliases=["whoami"])
async def spoof(ctx):
    s = ctx.client._spoof
    await ctx.reply(
        f"**Fingerprint**\n"
        f"UA: `{s.profile.user_agent}`\n"
        f"Locale: `{s.profile.locale}` / TZ: `{s.profile.tz}`\n"
        f"Build: `{s.build_number}`\n"
        f"Installation ID: `{s._installation_id}`"
    )

Invoke it with .spoof (or .whoami) to see the exact values being sent to Discord on every request.

Get Started

Core Concepts

Guides

Browser Fingerprint Spoofing in alterself Selfbots

How Identity Is Seeded

Chrome Version Resolution

Build Number Resolution

Manual Build Refresh

X-Super-Properties

App State Tracking

Spoof Info Command

​How Identity Is Seeded

​Chrome Version Resolution

​Build Number Resolution

​Manual Build Refresh

​X-Super-Properties

​App State Tracking

​Spoof Info Command

How Identity Is Seeded

Chrome Version Resolution

Build Number Resolution

Manual Build Refresh

X-Super-Properties

App State Tracking

Spoof Info Command