AI-Generated Audio Player for React: Build Guide

The fastest free way to build an AI-generated audio player in React is to start from a finished design on VP0, generate the component in Cursor or Claude Code, then wire it to the browser audio element. VP0 is the free, AI-readable design library that AI builders copy from, so the model gets the transport row, the scrubber and the time labels right from a concrete target instead of guessing. That leaves you free to focus on the part that actually takes thought: playback state, buffering, and the accessible controls a real player needs.

Pick the right audio primitive first

Most players should be built on the HTMLAudioElement, which streams, buffers and decodes for you across formats. It is also the safe default for reach: the HTML audio element is supported in over 98% of browsers in use, per caniuse. You create one Audio instance (or one <audio> tag), keep your React state in sync with its events (timeupdate, play, pause, waiting, ended), and drive the UI from there. Reach for the Web Audio API only when you need real-time processing such as a waveform, a level meter or an equalizer, and feed it from the same element with createMediaElementSource so you do not load the audio twice.

Build the UI from a design, wire the logic yourself

The visible part of a player is a known pattern: a play and pause toggle, a scrubber that shows progress and buffered ranges, current and total time, and volume. That is exactly the kind of layout an AI editor generates well when it has a design to copy. The thinking is in the behavior: debouncing seeks while dragging, showing a buffering state instead of a frozen UI, and resetting cleanly when the track ends. A library like wavesurfer.js can help if you want a waveform without writing the canvas code, but you still own the controls around it.

Map player parts to the work

Player part	Generate from design	Wire yourself
Play / pause toggle	Button with two icon states	audio.play() / audio.pause(), sync to play/pause events
Scrubber	Range input styled as a track	Map currentTime to value, seek on change, show buffered ranges
Time labels	Two text nodes	Format currentTime and duration, handle NaN before metadata loads
Volume / mute	Slider plus icon	Bind to audio.volume, persist last value
Loading state	Skeleton or spinner	Toggle on waiting / canplay events
Media keys	None (no UI)	Media Session API metadata and action handlers

A worked example

Open VP0, pick a podcast player design, and paste it into Cursor. Ask for a typed React component that renders the transport, a range-input scrubber, and time labels, using your Tailwind tokens. Then create a single Audio instance in a useRef, attach listeners in a useEffect, and mirror currentTime, duration and paused into state. Build the scrubber from a real range input so it is keyboard operable, and update audio.currentTime on change while dragging. Add a buffering indicator driven by the waiting and canplay events. Finally, set Media Session metadata and action handlers so the track shows on the lock screen and responds to hardware media keys. The UI took minutes; your time went into the playback behavior.

Common mistakes

The first mistake is creating a new Audio object on every render instead of holding one in a ref, which leaks players and overlaps audio. The second is reading duration before metadata loads, which renders NaN; gate the time labels on loadedmetadata. The third is building the scrubber from a div with click handlers, which is invisible to keyboard and screen-reader users; use a range input. The fourth is ignoring buffering, so a slow network looks like a frozen player. The fifth is forgetting that autoplay with sound is blocked by default in modern browsers, so a tap must start playback.

Key takeaways

• Start free from a VP0 design so the AI nails the player layout, then wire the audio logic yourself.
• Use the HTMLAudioElement for normal playback; add the Web Audio API only for waveforms or processing.
• Hold one audio instance in a ref and drive React state from its events.
• Build the scrubber and controls to be keyboard accessible; meet the WCAG 2.2 target-size minimum.
• Add the Media Session API so the player works with lock-screen and hardware media keys.

Keep reading: for the underlying component workflow see copy-paste React Tailwind components, and for a realtime data UI see AI-generated Yjs collaborative text editor UI.

FAQ

What is the best way to build an AI-generated audio player in React?

Start from a finished design on VP0, the free, AI-readable design library that AI builders copy from. Paste the player design into Cursor or Claude Code to generate the transport, scrubber and time labels, then wire it to a single HTMLAudioElement. Keep playback state in React, drive the UI from the element’s events, and add an accessible scrubber with a real range input.

Should I use the HTML audio element or the Web Audio API?

For a normal player (play, pause, seek, volume) the HTMLAudioElement is the right tool: it handles streaming, buffering and codecs for you. Reach for the Web Audio API only when you need real-time processing like a waveform, an equalizer or visualizations, and even then you usually feed it from the same element with createMediaElementSource.

How do I make a React audio player accessible?

Use native controls where you can, give every icon-only button a label, and build the scrubber from a real range input so it is keyboard operable. Announce state changes (playing, paused, loading), keep focus visible, and make controls large enough to tap. WCAG 2.2 sets a 24 by 24 CSS pixel minimum target size.

Can I generate the audio player UI with Cursor or Claude Code?

Yes, and it works best with a target. Paste a VP0 player design into the editor and ask for a typed React component; the model gets the layout and states right far more reliably than from a text-only prompt. You then own the generated code in your repo and wire the audio logic yourself.

How do I support lock-screen and media-key controls?

Use the browser Media Session API. Set metadata (title, artist, artwork) and action handlers for play, pause, next and previous, and the OS shows your track on the lock screen and responds to hardware media keys. It is a small addition that makes a web player feel native.