Server-Sent Events (SSE) Formatter — Build and Debug Real-Time Streams

How to Use the SSE Event Formatter:

1. Load a Preset (Optional): Click any preset button at the top to pre-fill all fields with a real-world SSE pattern. Simple loads a plain data-only event. Named Event shows a typed JSON event with an id. Multi-line demonstrates streaming chunks as separate data fields. With Retry sets a custom reconnection delay. Heartbeat shows a keep-alive comment-only message. Each preset can be edited after loading.

2. Enter a Comment (Optional): The comment field renders as a line starting with : (colon-space). Per the SSE specification, comment lines are completely ignored by the browser's EventSource client and are used to keep the connection alive during idle periods. Type any text — "ping", "keep-alive", or server metadata — and it will appear as : your text in the formatted output.

3. Enter an Event ID (Optional): The id field sets the event identifier. The browser stores this value and sends it as a Last-Event-ID header on reconnection, allowing the server to resume the stream from the correct position after a disconnect. Use sequential integers, UUIDs, or timestamps as appropriate for your stream design.

4. Enter an Event Type (Optional): The event field sets the event type name. If omitted, the browser dispatches the event as a generic "message" event and your addEventListener("message", handler) will receive it. If set, use a named event listener — addEventListener("update", handler) for event: update. Event type names should not contain whitespace.

5. Enter the Data Payload: The data textarea is the main content of the event. For JSON payloads, paste the serialised JSON on a single line. For multi-line streaming responses, press Enter to add a new line — each line in the textarea becomes a separate data: field in the formatted output. The browser concatenates multiple data fields with a newline when constructing the event data property.

6. Enter a Retry Value (Optional): The retry field tells the browser how many milliseconds to wait before attempting to reconnect after the stream drops. Enter a non-negative integer only — decimals and negative values are not valid per the SSE specification. A common value is 3000 (3 seconds). If omitted, the browser uses its default reconnection interval (typically a few seconds).

7. Read the Stats Row: Three metrics update instantly above the output: Fields (number of active SSE fields in the message), Data lines (how many data: lines were generated from the data textarea), and Bytes (the total byte size of the formatted message including the terminating blank line).

8. Switch Between Formatted and Escaped Views: The Formatted view shows the message exactly as it would appear on the wire, with real line breaks and a trailing blank line. The Escaped view shows the literal \n characters — useful for constructing the string in code (e.g., when writing a Python/Node.js SSE endpoint that builds the response string manually).

9. Copy the Message: Click Copy to copy the formatted SSE message string (with actual newlines) to your clipboard. Use it in curl to test an SSE endpoint, in Postman's response body, or directly in server-side code. The copied text always includes the double-newline terminator required by the SSE specification.

10. Test Your Endpoint: Paste the formatted message into a tool like curl or Postman to simulate an SSE response. A valid SSE response requires Content-Type: text/event-stream and Transfer-Encoding: chunked or HTTP/2 streaming. Each event in the stream must end with a blank line (\n\n).

Common Use Cases:

• SSE endpoint development: Format test events to verify your EventSource client parses id, event, data, and retry fields correctly before integrating with a live stream.
• Streaming LLM responses: Build multi-line data messages that simulate chunked text from an AI model to test your frontend streaming UI.
• Real-time notification systems: Construct named events (event: notification) with JSON payloads to test browser-side event listeners.
• Keep-alive debugging: Generate heartbeat comment messages (: ping) to verify that your SSE middleware does not drop idle connections.
• Reconnection testing: Set a retry field to test that your client respects the server-specified reconnection delay rather than using the browser default.
• SSE proxy testing: Format edge-case messages (empty data, multi-line data, missing fields) to verify your SSE proxy or middleware handles all valid SSE shapes correctly.
• Documentation and spec verification: Use the escaped view to confirm the exact byte sequence of a message when writing SSE protocol documentation.

Tips and Best Practices:

• Every valid SSE message must end with a blank line (\n\n). The formatter adds this automatically — do not add it manually in the data field.
• JSON payloads must be on a single line when used as SSE data. Newlines inside JSON would create multiple data: fields, and the browser would concatenate them with \n, producing broken JSON.
• Use the Multi-line preset to see how streaming token-by-token responses work — each token on a new textarea line becomes a separate data: field.
• The id field is optional but strongly recommended for any stream that clients may reconnect to. Without it, the browser cannot resume the stream after a network drop.
• Comments (: lines) are useful for keep-alive pings but generate zero data on the client side. Do not rely on them to carry information.
• The retry value is a hint to the browser, not a guarantee — some browsers cap the minimum reconnection delay regardless of the retry field.
• Use named events (event: type) to fan out different event types over a single SSE connection, with separate addEventListener calls on the client.
• Switch to the Escaped view when writing server code to see the exact string your endpoint must produce: fields joined by \n and terminated by \n\n.