Azure Speech Fast Transcription (2025-10-15) returns masked word (*******) even with profanityFilterMode=None

Question

Description

We are using Azure AI Speech Fast Transcription REST API.

Endpoint

POST /speechtotext/transcriptions:transcribe?api-version=2025-10-15

Request

{ "audioUrl": "<audio-url>", "locales": [ "en-US" ], "properties": { "punctuationMode": "DictatedAndAutomatic", "profanityFilterMode": "None" } }

Response

{

"combinedPhrases": [

{

  "text": "*******."

}

],

"phrases": [

{

  "text": "*******.",

  "locale": "en-US",

  "confidence": 0.28728607

}

]

}

Expected behavior

The spoken word, which is not intended as profanity.

Since profanityFilterMode is set to None, we expect the recognized text to be returned without masking.

Actual behavior

The response still contains:

*******. Questions Is this expected behavior? Is profanityFilterMode=None supported for the Fast Transcription API (2025-10-15)? Can low-confidence recognition still result in masked output? Is there any way to determine why a word was masked? Could this be a service issue with the transcription model?

Answer 1

Hello aassshhh,

Greetings! Thanks for raising this question in Q&A forum.

Based on the behavior you described, this does not appear to be the expected result when profanityFilterMode is explicitly set to None. However, because you are using the newer Fast Transcription API version (2025-10-15), this could be related to model-side handling, confidence scoring, or a service-side issue that requires review by the Azure Speech engineering team.

1. First, verify that the request payload received by the service exactly contains:

      "properties": {
       "profanityFilterMode": "None"
      }
   

   and that there are no policy or middleware transformations modifying the request. Test the same audio with a clearly non-profane sample that is recognized with high confidence. If masking still occurs, it helps confirm the issue is not specific to the spoken word. Compare the result with another supported Speech-to-Text API version, if available in your environment, to determine whether the behavior is specific to API version 2025-10-15. Capture the following details and open a support request if the issue persists:
   • Speech resource region
     • Request timestamp (UTC)
       • Correlation/Request ID from the response headers
         • A sanitized sample audio file that reproduces the issue

Since there is currently no public documentation indicating that profanityFilterMode=None should still return masked text, the next action is likely with the Azure Speech product team or Microsoft Support to validate whether this is a known issue, intended model behavior, or a regression in the Fast Transcription service. They can review backend logs and confirm why the token was masked.

If this answer helps you kindly accept the answer which will help others who have similar questions

Best Regards,

Jerald Felix.