Skip to main content
Back to Dev generators

Dev

Mock Kafka Message Generator

Used by developers, writers, and creators worldwide.

A mock Kafka message generator removes the friction of writing consumer tests without a live broker. This tool produces complete Kafka record objects — topic name, partition, offset, UUID key, typed headers, and a JSON payload — across five real event domains: user.created, order.placed, payment.processed, inventory.updated, and session.started. Each field mirrors exactly what a real consumer receives, so output pastes directly into a Spring Kafka test or a Kafka Streams TopologyTestDriver. Set your topic name, choose an event type, and generate up to a full batch in seconds. Developers building event-driven microservices use it to skip hand-crafting realistic fixture data from scratch.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Enter your Kafka topic name in the Topic Name field to match your actual topic, e.g. order-service.events.
  2. Select the Event Type that matches the domain you are testing — user.created, order.placed, or payment.processed.
  3. Set the How Many counter to the number of records your test scenario requires, then click Generate.
  4. Copy the generated JSON array and paste it into your unit test, MockConsumer setup, or kafka-console-producer input file.
  5. Adjust individual field values in the copied payload to cover edge cases like null amounts or missing user IDs.

Use Cases

  • •Seeding a Kafka Streams TestInputTopic with realistic user.created events inside a JUnit 5 test suite
  • •Testing Spring Kafka @KafkaListener offset-commit logic using MockConsumer with generated record batches
  • •Creating dead-letter queue handler fixtures by generating payment.processed messages with edge-case field values
  • •Demoing Kafka record anatomy — headers, UUID key, partition, offset — during microservices onboarding sessions
  • •Replaying order.placed message batches through kafka-console-producer against a local Docker Kafka broker

Tips

  • →Match the topic name exactly to your environment's naming convention so generated messages need no editing before use in tests.
  • →Generate a batch of 10 or more, then cherry-pick specific records to cover both happy-path and failure scenarios in the same test suite.
  • →The message key is a UUID by default — replace it with a fixed value when testing partition-ordered processing to ensure all test records land on the same partition.
  • →Copy the headers object into a Spring Kafka MessageHeaders or a Flink KafkaRecordSerializationSchema to test header-aware consumer branches.
  • →Combine payment.processed and user.created events in a single test to verify that your consumer correctly routes multiple event types from the same topic.
  • →When testing offset-commit logic, edit the offset field in consecutive generated records to be sequential integers starting from a non-zero value, simulating a mid-stream consumer restart.

FAQ

how do I use generated kafka messages in a topologytestdriver test

Copy the generated JSON value into your test via TestInputTopic.pipeInput(), using the key field as the record key and mapping the headers object to a Kafka Headers instance. No broker is needed — TestInputTopic handles everything in-process. For Spring Kafka, drop the same payload into a MockConsumer or pass the key and value to an EmbeddedKafkaBroker to drive a real @KafkaListener.

are mock kafka messages safe to paste into ci pipelines or share with teammates

Yes. All messages are generated entirely in your browser — no data is sent to any server and no broker is contacted. The payloads are fully synthetic, so there is zero risk of leaking production event data. Commit the JSON output as a static test fixture and reference it in your pipeline like any other resource; tests using MockConsumer or TopologyTestDriver need no network access at all.

what's the difference between the kafka message key and the partition field

The key is a value you attach to a record — here a UUID — that Kafka's default partitioner hashes to decide which partition receives it. The partition is the broker-assigned integer bucket within the topic. Kafka guarantees ordering only within a single partition, so using a consistent key (like a user or order UUID) ensures all related events land in sequence.