A dev.to post published under the EasyMusic.AI account sets out a design checklist for what happens between a user picking an audio file and pressing upload. The author states plainly that the article was generated with AI for the official EasyMusic.AI account and that it is a design checklist for developers rather than a report of production tests or a description of a deployed backend. That framing matters for how the piece should be read: it is a set of proposals, not measured results.
The checklist's first proposal is that selection should be visible. After a file is chosen, the interface should show its name and size next to a clear control for replacing it. The author points to the browser File API as the source of those properties and notes that the MIME type it exposes can be empty — a caveat that matters for anyone planning to branch on file type. For local preview, the post suggests an object URL and says that URL should be released once the preview is no longer needed, citing MDN's File API guide.
MDN's guide, last modified on 18 September 2025, documents the primitives involved. A FileList holds the File objects a user selected, reachable either through the input element's files property or through a change event listener. Each File exposes three read-only attributes: the name without path information, the size in bytes as a 64-bit integer, and the MIME type as a string that is empty when the type cannot be determined. MDN's own size-display example walks the FileList, sums the byte counts and converts the total into prefixed units.
The dev.to post's second proposal is to keep "selected" and "uploaded" as separate states, so a user does not have to guess whether an unreleased demo has already left their device. If an implementation uploads automatically on selection, the author argues the interface should say so before selection rather than showing a message that implies a local-only preview. This is a state-modelling recommendation, not a claim about any specific product's behaviour.
A third idea holds that every check ought to carry a narrow responsibility. Someone can use a duration check to shorten a recording prior to waiting on a transfer, while an obviously oversized selection is caught fast by a file-size check. Neither check, the author states plainly, proves a file is valid or safe for server processing; client-side checks amount to early feedback alone, since a modified client is able to bypass them, meaning independent limits and media inspection remain necessary on the server. Treating a filename extension as evidence of the contents' format is another practice the post cautions against.
On error copy, the post recommends phrasing that names an action the person can take, giving the example of telling someone a selection exceeds the upload limit and to choose a smaller file, rather than a generic invalid-input message. It adds that the actual configured limit should be shown in the product and kept consistent with the server limit, and that documentation should not invent a limit because another tool uses it.
Its own section is given to replacement and cancellation. Should file A be swapped for file B by a user, the author says B's details must not be overwritten by a slow result belonging to A, and the old preview plus old validation result ought to be cleared — tracking which selection owns each asynchronous result is what this requires. An equally explicit contract is what cancellation deserves, the post argues, since three distinct operations exist: cancelling an already-started processing job, cancelling a network upload, and cancelling a local preview. Only when the relevant layer confirms it should the interface claim an operation stopped.
Before release, the post closes by proposing a behaviour matrix to run: an unsupported format, an oversized file, an empty file, a valid short recording, a cancellation during upload, and a replacement during validation, plus one keyboard-only pass through selection, replacement and submission at minimum. The author labels these suggested checks, not claimed test results, and recommends logging three things for each run — the message the user actually saw, whether any data left the device, and whether retrying the action succeeds. The post argues that record tells more than a screenshot of a green progress bar.
MDN's guide supplies the mechanics that several of these checks would sit on. It documents hiding the native file input and triggering the picker either through a click() call on the input or through a label element, with the important accessibility caveat that a label-triggered input must not be hidden with display:none or visibility:hidden, since that would remove keyboard accessibility; the visually-hidden technique is offered instead, along with a visible focus cue on the label.
The same guide covers drag and drop: a drop zone registers dragenter, dragover and drop listeners, the first two suppressing default behaviour, and the drop handler reads the file list from the event's dataTransfer field before passing it to the same handling function used for input selection. That means the post's checklist items — showing name and size, validating, replacing — apply equally to files that arrive by drop, which is a practical detail for anyone building an audio intake screen.
MDN also documents object URL lifecycle. Each call to URL.createObjectURL() produces a unique string even for a file that already has one, and each must be released; while release happens automatically when the document unloads, the guide says pages that use object URLs dynamically should revoke them explicitly. It notes one deliberate exception in its thumbnail example: the URL is not revoked immediately after the image loads, because doing so would break interactions such as right-clicking to save or opening the image in a new tab, and recommends revoking when the element is removed from the DOM.
For uploads with progress, MDN's example uses XMLHttpRequest rather than the Fetch API, explaining that progress reporting is still not supported by Fetch and linking to the open standardization discussion. The example attaches a progress listener to the upload object, computes a percentage from loaded and total when the length is computable, and forces the indicator to 100% on the load event to avoid granularity quirks. That is a concrete constraint for developers who want a progress bar on an audio upload and had assumed Fetch would cover it.
Read together, the two sources describe a division of labour rather than a product. MDN documents what the browser exposes — file metadata, selection events, object URLs, upload progress — and the dev.to post proposes how a developer might arrange those pieces into a pre-upload screen. The post's own disclaimer that it is not a report of production tests means none of its recommendations come with measured outcomes attached.
For freelancers and developers building audio or media intake, the practical implication is that the cheap checks are worth doing early and worth scoping honestly. Showing name and size, warning on an obviously oversized file, and offering a duration readout before transfer all reduce wasted waiting, and all of them are buildable from documented File API properties. The editorial judgement here is that the checklist's value lies in its boundaries: it repeatedly says what a client check cannot prove, which is the part most likely to be skipped when a screen is built quickly.
The tradeoffs are visible in the sources. Client-side checks improve feedback but are skippable, so server-side limits and media inspection remain necessary — the post states this directly. Object URLs make previews easy but add a lifecycle to manage, and MDN's own example shows the tension between revoking promptly to free memory and keeping a URL alive for user interactions. Progress reporting pushes developers toward XMLHttpRequest, an older API, for a capability Fetch does not yet standardize.
What remains unknown is substantial. Neither source names a specific product, version, limit value or measured failure rate. The dev.to post does not describe a deployed backend, does not report test results, and does not say which of its suggested checks any real implementation performs. MDN's guide is reference documentation with illustrative examples, not a survey of how upload interfaces behave in practice. No pricing, availability or performance figures appear in either source.
The useful conclusion is modest and supported: the browser already exposes the file name, size and MIME type, plus selection, preview and progress events, and a developer can build a pre-upload screen from those pieces. The dev.to checklist offers one proposed arrangement of them, explicitly labelled as suggestions rather than findings. Treat it as a starting point for a behaviour matrix, and treat MDN's caveats — empty MIME types, object URL release, keyboard-accessible hidden inputs, Fetch's missing progress support — as the constraints that will shape whatever gets built.