Google's QuickDraw component on GitHub

What the repository is — and what it is not

The project is a web component built on Polymer/Lit that embeds individual Quick, Draw! doodles into a page. The ambition is deliberately small: an element such as <quick-draw category="apple"> loads a drawing and paints it onto a canvas.

What it is not is often misunderstood: it is neither an open-source version of the game nor does it contain the classifier. There is no training code and no model. Anyone looking for the recognition will not find it here — the published side of Quick, Draw! comprises the data and the tools to display it, not the network that guesses in the original game.

Source: googlecreativelab/quickdraw-component.

The component: stroke data in the browser

The component exposes properties for category, index, stroke colour and width, dimensions and an animation mode. Internally it draws onto a canvas. The data arrives as separate X and Y point lists per stroke; when timing values are included, the drawing can be replayed in its original motion.

<quick-draw
  category="apple"
  key="API_KEY"
  animate>
</quick-draw>

The real insight lies in what becomes visible here: a Quick, Draw! drawing is not a picture but a sequence of movements. It can be played back like a recording. Exactly this dual nature is what makes the dataset usable for both sequence models and image classification — the RNN versus CNN comparison follows that thread.

The API layer

The repository ships an Express service that serves individual drawings — the number of doodles in a category, a specific drawing or a random one:

GET /drawing/:category/count
GET /drawing/:category?id=random&isAnimated=false

It distinguishes simplified data from raw, time-stamped data. Animation requires the raw variant with timestamps; a static rendering only needs the simplified form.

Self-hosting: a warning worth taking seriously

The README explicitly advises against building serious projects on the demo endpoint. That is not a formality: an archived repository means nobody is on the hook for availability any more. Anyone using the component today should copy the doodle files into their own storage bucket and run the API themselves.

Two further points come with the project's age. Polymer is now considered legacy — in a new project you would write the handful of canvas lines directly rather than take on a framework dependency of that vintage. And API access requires a key, which is awkward for a purely client-side integration because the key inevitably becomes public.

Why DrawLa built its own playback

The connection is closer than it first appears: DrawLa's bots do essentially what this component does — they replay a real Quick, Draw! recording stroke by stroke. Just not in the browser, but on the server.

The difference is decisive. A browser component paints a finished drawing onto the page. A bot has to be part of the game: its drawing progress is broadcast to every player as a stroke_update so they can watch it live, and it is continuously submitted to the same recognition a human drawing goes through. The bot can therefore fail to be recognised and lose the round.

That is why playback lives on the server here: it has to be coupled to the round state, to the pace of the round, and to the same scoring humans get. A display component cannot do that — it is built for a different purpose.

When it is still worth a look

For anything that shows Quick, Draw! data rather than evaluating it, the repository remains the obvious template: illustrations on web pages, placeholder imagery, data exploration. The combination of storage files, a serving API and canvas playback in the frontend is a clean, simple architecture.

Anyone wanting to recognise instead will find nothing here — the other direction is described in QuickDraw with PyTorch: normalise strokes into an image and train a CNN on it. The data behind both routes is explained in the Quick, Draw! dataset.