How to Decode a SAML Response (Step-by-Step Guide) (Updated 2027)

A SAML response can look confusing when you first see it. It contains encoded data, XML tags, authentication details, and information about the user trying to sign in. If you are troubleshooting a Single Sign-On (SSO) problem, reading this data can help you find the cause.

To decode a SAML response, you need to convert its Base64-encoded value into readable XML. You can do this with PowerShell, Linux commands, macOS Terminal, or a browser debugging tool such as SAML-tracer.

This guide explains how to capture a SAML response, decode it, read its main fields, and identify common authentication errors. It also shows how to protect sensitive login information during testing.

What Is a SAML Response?

A SAML response is an XML-based message sent by an Identity Provider (IdP) to a Service Provider (SP) during a login process.

SAML stands for Security Assertion Markup Language. It is an open standard that allows users to sign in to different applications through one identity system.

For example, an employee may use a company Microsoft account to access an internal business application. The application receives a SAML response from the company’s identity provider to confirm the user’s identity.

A SAML response usually contains:

• Issuer: Identifies the system that created the response.
• Status: Shows whether authentication succeeded or failed.
• NameID: Identifies the user.
• Assertion: Contains information about the authenticated user.
• Audience: Identifies the application that should accept the assertion.
• Conditions: Shows when and where the assertion can be used.
• Signature: Provides a way to verify the message’s authenticity.

The response is commonly sent through an HTTP POST request as a Base64-encoded value. Decoding it changes the encoded text into readable XML. It does not automatically verify the digital signature or prove that the message is trusted.

Example 1:

An employee signs in to a company application using their Microsoft account. The identity provider sends a SAML response containing the employee’s identity information and authentication result.

This example shows how SAML helps an application confirm a user’s identity without asking the employee to create another password for that application.

How to Decode a SAML Response

You can decode a SAML response using several methods. The best option depends on your operating system and whether you need to inspect one response or troubleshoot SSO regularly.

The basic process is:

1. Capture the SAMLResponse value.
2. Copy the encoded data.
3. Decode it from Base64.
4. Save or view the resulting XML.
5. Inspect the authentication fields.

Here are the main methods.

Method 1: Decode a SAML Response Using PowerShell

If you use Windows, PowerShell provides a built-in way to decode Base64 data. You do not need to install another application.

Follow these steps:

Step 1: Capture the SAML response

Open your browser and reproduce the SSO login process. Find the SAMLResponse value using browser Developer Tools.

Step 2: Copy the encoded value

Copy the complete Base64 string. Make sure you do not copy the field name or unrelated form data.

Step 3: Open PowerShell

Open the Windows Start menu, search for PowerShell, and launch it.

Step 4: Decode the response

You can use the following command:

$encoded = Get-Content -Raw ".\saml-response.txt"
$xml = [System.Text.Encoding]::UTF8.GetString(
    [System.Convert]::FromBase64String($encoded.Trim())
)
$xml | Set-Content -Encoding utf8 ".\decoded-saml.xml"

Before running the command, save your copied Base64 value in a file named saml-response.txt in the current folder.

Step 5: Open the XML file

Open decoded-saml.xml using Notepad or a code editor.

You should now see readable XML containing the response, assertion, issuer, status, and other authentication information.

Example 2:

An IT administrator receives a Base64-encoded response while investigating an employee’s failed SSO login. The administrator uses PowerShell to convert the data into an XML file and checks the NameID and status fields.

This allows the administrator to inspect the login message without relying on an online decoder.

Method 2: Decode a SAML Response Using Linux

Linux users can decode a SAML response with the built-in base64 command.

Follow these steps:

Step 1: Open your Linux Terminal.

Step 2: Save the encoded response in a file named saml-response.txt.

Step 3: Run this command:

base64 --decode saml-response.txt > decoded-saml.xml

Step 4: Open the decoded file:

cat decoded-saml.xml

For easier reading, you can also use an XML formatting tool installed on your computer.

The decoded output will contain the XML structure of the SAML message.

Example 3:

A Linux system administrator receives a SAML response from an identity provider. They run the Base64 decoding command and open the resulting XML file to check whether the application received the expected user information.

This method is useful for technical teams that work with Linux servers and command-line tools.

Method 3: Decode a SAML Response Using macOS Terminal

macOS users can also decode Base64 data without installing extra software.

Follow these steps:

Step 1: Open Terminal.

Step 2: Save the encoded response in saml-response.txt.

Step 3: Run the following command:

base64 -D -i saml-response.txt -o decoded-saml.xml

Step 4: Open the XML file:

open decoded-saml.xml

Your Mac will open the file using its default application.

If you prefer a command-line view, use:

cat decoded-saml.xml

Example 4:

A developer uses a Mac to test a new SSO connection. They capture the SAML response, decode it in Terminal, and check whether the expected application appears in the Audience field.

This helps the developer check whether the identity provider is sending the response for the correct application.

Method 4: Decode a SAML Response Using SAML-Tracer

SAML-tracer is a browser extension that captures SAML messages and displays their decoded contents.

It is useful for developers and IT administrators who regularly troubleshoot SSO connections.

Follow these steps:

1. Install SAML-tracer from a trusted browser extension store.
2. Open the extension.
3. Start the SSO login process.
4. Reproduce the login issue.
5. Look for the captured SAML request and response.
6. Select the response to view its decoded XML.
7. Inspect the available fields.

The extension can also capture other authentication messages, including WS-Federation traffic.

Example 5:

A developer is testing SSO between a business application and an identity provider. They open SAML-tracer before signing in and use the captured response to check which user attributes the identity provider sends.

This method saves time because the extension can capture and display SAML messages during the login process.

Method 5: Decode a SAML Response Using Browser Developer Tools

You can also capture a SAML response directly from Chrome, Edge, or Firefox.

You do not need a special extension for this method.

Step 1: Open Developer Tools

Open the application login page and press F12.

Step 2: Select the Network tab

Open the Network tab in Developer Tools.

Step 3: Enable Preserve Log

Turn on Preserve log so browser activity remains visible during navigation.

Step 4: Reproduce the login issue

Try signing in through your identity provider.

Step 5: Find the SAML POST request

Look through the network activity for a request related to SSO. Select the relevant POST request.

Step 6: Find the SAMLResponse field

Open the request’s Payload or form data section. Find the field named SAMLResponse.

Step 7: Copy the encoded value

Copy the value and decode it locally using PowerShell, Linux, or macOS.

You can now inspect the XML response.

Example 6:

A user receives an SSO error when opening a company dashboard. An administrator opens Chrome Developer Tools, finds the SAML POST request, and copies its SAMLResponse field for local inspection.

This method is helpful when you need to capture the exact response sent during a failed login attempt.

What Does a Decoded SAML Response Look Like?

After decoding a SAML response, you will see an XML document.

It contains different elements that describe the authentication process and the user’s identity.

Here is a simplified example:

<samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_response123"
    Version="2.0"
    IssueInstant="2026-11-02T10:00:00Z">

    <saml:Issuer>
        https://idp.example.com
    </saml:Issuer>

    <samlp:Status>
        <samlp:StatusCode
            Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>

    <saml:Assertion
        ID="_assertion123"
        Version="2.0">

        <saml:Issuer>
            https://idp.example.com
        </saml:Issuer>

        <saml:Subject>
            <saml:NameID>
                user@example.com
            </saml:NameID>
        </saml:Subject>

    </saml:Assertion>

</samlp:Response>

This is a simplified teaching example. A real response usually contains more fields, such as conditions, authentication statements, attributes, and signature information.

The example also uses fictional account details and does not represent a valid signed login message.

Main Parts of a SAML Response

Here are the main XML elements you may find in a decoded message.

XML Element	Meaning
Response	Contains the authentication response.
Issuer	Identifies the system that issued the message.
Status	Shows the result of the authentication request.
StatusCode	Provides a specific success or error code.
Assertion	Contains information about the authenticated user.
Subject	Identifies the person or account.
NameID	Provides the user’s identifier.
Conditions	Defines the rules and validity period.
Audience	Identifies the intended application.
AttributeStatement	Contains additional user information.
AuthnStatement	Provides details about the authentication event.
Signature	Contains digital signature information.

These elements help you find the information needed to troubleshoot an SSO login.

Important Fields to Check After Decoding a SAML Response

Decoding is only the first step. You also need to inspect the fields to find possible configuration problems.

Here are the main fields to check.

1. Issuer

The Issuer identifies the identity provider that created the SAML message.

For example:

<saml:Issuer>
    https://idp.example.com
</saml:Issuer>

Compare this value with the identity provider configured in your service provider.

If the issuer does not match the expected value, the application may reject the response.

2. Status Code

The StatusCode shows whether the authentication request succeeded or failed.

A successful response may contain:

<samlp:StatusCode
    Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

A failed response may contain:

<samlp:StatusCode
    Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/>

A Responder status indicates that the identity provider could not complete the request. You may need to inspect any nested status code or status message to find the reason.

3. NameID

The NameID identifies the user in the SAML assertion.

Example:

<saml:NameID>
    user@example.com
</saml:NameID>

Check whether this value matches the username or email address stored in the application.

A mismatch may cause an account mapping or login error.

4. Audience

The Audience identifies the application that should accept the assertion.

Example:

<saml:Audience>
    https://app.example.com/saml
</saml:Audience>

Compare this value with the Audience URI configured in your service provider.

If the values do not match, the application may reject the assertion.

5. Destination

The Destination attribute identifies where the SAML response should be sent.

Example:

<samlp:Response
    Destination="https://app.example.com/saml/acs">

Check whether the destination matches the expected Assertion Consumer Service (ACS) URL.

An incorrect destination can prevent the application from accepting the response.

6. Conditions and Expiration Time

The Conditions element contains rules that control when an assertion can be accepted.

For example:

<saml:Conditions
    NotBefore="2026-11-02T09:55:00Z"
    NotOnOrAfter="2026-11-02T10:05:00Z">

These attributes describe the assertion’s validity period.

Check:

• NotBefore: The time from which the assertion can be accepted.
• NotOnOrAfter: The time after which the assertion cannot be accepted.
• AudienceRestriction: The applications allowed to accept the assertion.

Also check whether the server clocks are correctly synchronized. Differences between system clocks can cause time-related authentication errors.

7. AuthnStatement

The AuthnStatement provides information about the authentication event.

It may contain:

• Authentication time.
• Authentication session information.
• Authentication method.
• Session expiration details.

For example:

<saml:AuthnStatement
    AuthnInstant="2026-11-02T10:00:00Z"
    SessionIndex="_session123">
</saml:AuthnStatement>

This information can help you check whether the user completed the expected authentication process.

8. AttributeStatement

The AttributeStatement contains additional information about the user.

For example:

<saml:AttributeStatement>

    <saml:Attribute Name="email">
        <saml:AttributeValue>
            user@example.com
        </saml:AttributeValue>
    </saml:Attribute>

    <saml:Attribute Name="role">
        <saml:AttributeValue>
            administrator
        </saml:AttributeValue>
    </saml:Attribute>

</saml:AttributeStatement>

An application may use these attributes to assign user roles, email addresses, departments, or other account details.

Check whether the attribute names and values match what the application expects.

9. Digital Signature and X.509 Certificate

A digital signature helps the service provider verify that the SAML message has not been changed and was signed using a trusted key.

The XML may contain a Signature element and an X.509 certificate.

Check the following:

• Is the signature present where the service provider expects it?
• Does the signing certificate match the configured identity provider certificate?
• Is the certificate trusted and valid?
• Does the signature verification process succeed?

Simply decoding the XML does not verify its signature. Use a SAML validation tool or the service provider’s authentication system to perform that check.

How to Troubleshoot Common SAML Response Errors

A decoded SAML response can help you find the cause of many SSO login problems.

Here are common issues and what to check.

1. Invalid SAML Response

Possible causes:

• Incorrect XML structure.
• Missing required fields.
• Invalid Base64 data.
• Incorrect SAML version.
• Unsupported response format.

What to check:

Make sure the response decodes correctly and contains the required XML elements. Also check the application logs for a more specific error.

2. Audience Mismatch

Possible cause:

The Audience value in the assertion does not match the service provider’s configured Audience URI.

What to check:

Compare the Audience value in the decoded XML with the value in your SSO settings.

Both systems must use matching values.

3. Invalid NameID

Possible cause:

The identity provider sends a different username or email address than the application expects.

What to check:

Compare the NameID with the user’s account identifier in the application.

Also check whether the application expects an email address, username, or another identifier format.

4. Signature Validation Failed

Possible causes:

• Incorrect signing certificate.
• Expired or replaced certificate.
• Invalid XML signature.
• Unsupported signature algorithm.
• Changes to signed XML content.

What to check:

Compare the identity provider’s signing certificate with the certificate configured in the service provider.

Do not treat a readable XML response as proof that its signature is valid.

5. SAML Response Expired

Possible cause:

The assertion has passed its allowed validity period.

What to check:

Inspect the NotBefore and NotOnOrAfter values inside the Conditions element.

Also check the clocks on the identity provider and service provider.

6. Incorrect ACS URL

Possible cause:

The identity provider sends the response to an incorrect destination.

What to check:

Compare the Destination value with the configured ACS URL.

Check the service provider’s SSO settings for spelling mistakes, incorrect paths, or outdated URLs.

7. Missing User Attributes

Possible cause:

The identity provider does not send the attributes required by the application.

What to check:

Open the AttributeStatement element and review the available attributes.

Compare the attribute names with the application’s requirements.

Example 7:

A company employee can authenticate through the identity provider, but the application displays an access denied message. The administrator checks the AttributeStatement and finds that the required department attribute is missing.

This example shows why a successful authentication response does not always mean the application will grant access.

Common Problems When Decoding a SAML Response

Sometimes the decoding process fails before you can inspect the XML.

Here are a few common problems.

Problem	Possible Reason	What to Do
Invalid Base64 data	Incomplete or incorrect copied value	Copy the full SAMLResponse again.
Unexpected characters	URL encoding or extra form data	Check the original request and decode the correct value.
Empty XML output	Incorrect input or decoding command	Check the file contents and command options.
XML parsing error	Malformed or incomplete XML	Capture the response again.
Unreadable XML	XML formatting is missing	Use a local XML formatter.
Signature error	Certificate or signature mismatch	Check the configured signing certificate.
Login still fails	SAML settings do not match	Compare the issuer, audience, destination, and NameID.

What If the SAML Response Is URL-Encoded?

Some captured SAML values may contain URL-encoded characters.

For example:

• %2B represents +.
• %3D represents =.
• %2F represents /.

If the copied value is URL-encoded, you may need to URL-decode it before applying Base64 decoding.

For HTTP-Redirect binding, SAML messages may also use DEFLATE compression. In that case, the decoding steps are different from the usual HTTP-POST method.

Check which SAML binding was used before trying to decode the message.

Is It Safe to Decode a SAML Response Online?

You can find online tools that decode Base64 and display SAML XML. However, sending a real SAML response to an unknown website can expose sensitive information.

A SAML response may contain:

• User email addresses.
• Account identifiers.
• Authentication details.
• Session information.
• User attributes.
• Digital signatures and related security data.

For this reason, local decoding is the safer choice for production authentication data.

Use PowerShell, Linux Terminal, macOS Terminal, or a trusted local debugging tool whenever possible.

If you must use an online decoder, use fictional or properly sanitized test data. Never share a real production response, private key, session token, or other login secret with an unknown service.

Also, do not assume that a decoder verifies signatures. Decoding and security validation are two separate tasks.

Best Tools for Decoding and Inspecting SAML Responses

Different tools can help with different parts of SAML troubleshooting.

Tool	Main Use	Best For
PowerShell	Base64 decoding	Windows users
Linux Base64	Command-line decoding	Linux administrators
macOS Terminal	Base64 decoding	Mac users
SAML-tracer	Capturing and viewing SAML messages	Developers and IT teams
Browser Developer Tools	Finding SAML POST requests	Manual troubleshooting
XML editor	Formatting and reading XML	Developers
SAML validation tools	Checking SAML message security and settings	Identity administrators

Choose a tool based on your task. If you only need to convert Base64 into XML, a local command-line tool is enough. If you need to capture and inspect the full login process, SAML-tracer may be more useful.

FAQs About Decoding a SAML Response

1. What does it mean to decode a SAML response?

It means converting a Base64-encoded SAML message into readable XML. The decoded XML shows authentication details, user information, status codes, and other SAML fields.

2. Is a SAML response Base64 encoded?

For the common HTTP-POST binding, the SAML response is Base64 encoded before being sent through a form field. Other bindings may use different encoding and compression steps.

3. How do I decode a SAML response in Windows?

You can use PowerShell with the built-in FromBase64String() method. It converts the encoded value into readable XML without requiring an extra application.

4. Can I decode a SAML response without an online tool?

Yes. You can use PowerShell, Linux Terminal, macOS Terminal, or a local SAML debugging tool. These options help keep sensitive login data on your computer.

5. What is the difference between a SAML response and a SAML assertion?

A SAML response is the complete message sent by the identity provider. A SAML assertion is a section inside that message containing claims about the authenticated user.

6. How can I check whether a SAML response is successful?

Inspect the StatusCode element. A successful response commonly contains:

urn:oasis:names:tc:SAML:2.0:status:Success

However, you must also check the assertion, signature, conditions, and application settings.

7. Does decoding a SAML response verify its signature?

No. Base64 decoding only converts the encoded data into readable XML. Signature verification requires a separate process using the correct certificate and signature validation rules.

8. What is NameID in a SAML response?

NameID is an element that identifies the user in a SAML assertion. It may contain an email address, username, or another identifier based on the application’s configuration.

9. Why does my decoded SAML response show an expired assertion?

The assertion may have passed its allowed time period. Check the NotBefore and NotOnOrAfter values, and make sure the identity provider and service provider have correctly synchronized clocks.

10. Can I decode an encrypted SAML assertion?

Base64 decoding alone cannot reveal encrypted content. You need the correct private key and a suitable XML decryption process to read an encrypted assertion or NameID.

Conclusion

To decode a SAML response, capture the SAMLResponse value, convert its Base64 data into XML, and inspect the main authentication fields.

You can use PowerShell, Linux commands, macOS Terminal, or SAML-tracer to complete this task. Pay close attention to the Issuer, StatusCode, NameID, Audience, Destination, Conditions, and Signature when troubleshooting SSO problems.

If a login still fails after decoding, compare the response with your identity provider and service provider settings. Also check the application logs for more details.

For real production data, use local decoding tools and keep authentication information private. This will help you inspect SAML messages without sending sensitive login data to unknown websites.