Modern web development tends to lean heavily on JavaScript frameworks and UI libraries, especially for forms. However, before reaching for another dependency or a ready-made (but probably over-engineered) component, it’s worth remembering that HTML already includes a surprisingly capable set of <input> types… and there’s more than you might realise.
In this article, we’ll look at five lesser-used input types (and one powerful attribute) that you can start using right away, though we’ll also point out where they might need further browser support (and how you could help) along the way.
1. type="week"
Date inputs are very common, but what about when users might only need to select a week, rather than a specific day?
Lots of real workflows revolve around weeks, not specific dates, and HTML makes it very straightforward:
<label for="sprint-week">Sprint</label>
<input type="week" id="sprint-week" name="sprint">
The value comes back as an ISO string (2025-W06), which is great for backend parsing. The only catch is that this control isn’t yet supported in Firefox or Safari (desktop or iOS), where it simply falls back to a plain text field, so it works best as progressive enhancement until more browsers adopt it.
2. type="month"
If users could also select a date, then it’s only right that they could also choose an entire month when a full date picker would add unnecessary friction. The month picker gives a lightweight, scrollable UI for moving through months and years:
<label for="billing-cycle">Billing month</label>
<input type="month" id="billing-cycle" name="billing">
This is ideal for reporting dashboards, finance tools, subscription cycles, or analytics filters. As with week, though, Safari and Firefox on desktop still treat this as a text field, and iOS Safari only partially implements it, so it’s safest to pair it with simple validation or a fallback format for users on those browsers.
Both the month and week input types are promising, so fingers crossed they’ll become baseline soon.
3. type="color"
While many developers immediately install a JavaScript colour picker, browsers already ship a perfectly usable native one:
<label for="theme">Theme colour</label>
<input type="color" id="theme" name="theme" value="#ff6600">
This works across all modern browsers, including current Safari and mobile browsers, though older versions of Safari offered only limited support and UI differences still vary quite a bit between engines. Even so, for the majority of users in 2025, this input is stable enough to use without hesitation, particularly as we so often spot over-engineered component-based ones in the wild that, to be frank, are unnecessary.
4. type="range"
Range inputs are ideal for settings where precise numbers don’t matter, like brightness, intensity, zoom levels, or anything where a slider feels more natural than a numeric field:
<label for="intensity">Intensity</label>
<input
type="range"
id="intensity"
name="intensity"
min="0"
max="10"
step="1"
>
This control has excellent browser support going back many years. Styling them consistently can still be fiddly, and touch interactions can vary in precision, but for mainstream use this is one of the most reliable native controls you can lean on today.
5. type="file" + capture
This one’s a surprising one, but speaks to the power of the platform. HTML alone can open the camera, video recorder, or microphone directly on mobile devices, without JavaScript.
<label for="photo">Take a photo</label>
<input
type="file"
id="photo"
accept="image/*"
capture="camera"
/>
Mobile browsers often interpret this by launching the camera immediately, although the behaviour differs slightly between iOS Safari and Android Chrome, and most desktop browsers simply ignore capture and show a normal file picker.
Because you also don’t get control over camera resolution or settings, this is best treated as a convenience feature for mobile users rather than something your app should depend on as a core requirement, so bear that in mind. It’s not perfect, but it’s still pretty impressive.
You don’t need JavaScript for everything, and HTML still has a lot of capabilities hiding in plain sight. Some of these inputs aren’t universally implemented yet, but they’re supported enough to start using as progressive enhancements today. And the more developers adopt them, the more pressure browser vendors feel to make them baseline standards, so it’s worth doing your bit in this regard.
Browsers prioritise the features developers actually lean on — and these are well worth leaning on. So, let us know what you think and be sure to send your examples to us on socials.