diff --git a/develop-docs/sdk/telemetry/spans/implementation.mdx b/develop-docs/sdk/telemetry/spans/implementation.mdx
index f399bc103ac56..0cbf3ca570487 100644
--- a/develop-docs/sdk/telemetry/spans/implementation.mdx
+++ b/develop-docs/sdk/telemetry/spans/implementation.mdx
@@ -124,7 +124,7 @@ The `captureSpan` pipeline emits a `process_span` message that any consumer (e.g
 The consumer can then apply its logic to spans, similarly to how it might have applied it in event processors before. 
 SDKs having alternative processing patterns established can also use them. 
 
-```txt
+```js
 // in captureSpan:
 processed_span = client.emit("process_span", captured_span)
 
@@ -144,7 +144,7 @@ For event processors mutating data, we need to replace the mutation logic with s
 SDK-internally, this means configure the integration or call site that registers an event processor, to also register a hook to process that span.
 As written above, this could be realized via a client lifecycle hook, or a similar mechanism.
 
-```txt
+```js
 // someIntegration:
 
 client.addEventProcessor(event => {
@@ -169,7 +169,7 @@ This should be the first step we try when implementing span streaming.
 
 If this doesn't apply to the use case, we should pre-configure the SDK's `ignore_spans` option and leverage the existing span filtering logic to drop segments or child spans **upfront**.
 
-```txt
+```js
 // someIntegration:
 
 client.addEventProcessor(event => {