What microSD card should I buy for a dashcam fleet order?

TL;DR

For a dashcam fleet order, buy on three axes at once: capacity band the camera’s file system can actually address, a speed class the camera’s write pattern can sustain, and an endurance/wear profile matched to continuous loop recording. Get any one of those wrong and the fleet gets frame drops, corrupted last clips, or cards that die inside the warranty period.

Practical defaults for a first fleet order:

• Capacity: 32 GB if the camera only handles FAT32; 64 GB or 128 GB only where the camera firmware explicitly supports exFAT and the retention requirement justifies it.
• Speed class: match the class to the camera’s bitrate and write pattern — do not buy a higher class than the camera can use, and do not buy below the class the camera vendor specifies.
• Endurance: ask the supplier for a published endurance/TBW figure or write-cycle rating in writing. If they cannot supply one, treat that as a gap in the offer, not a detail.
• Lock-in: freeze controller family, flash vendor/lot policy, file system as shipped, and the exact marking on the card in the approved-sample record before the PO is placed.
• Verify: full-surface capacity verification and a sustained-write soak test on every lot, not just the first one.

The rest of this guide walks the checks a dashcam fleet buyer should run before signing a PO, in the order they matter.

Why dashcams are a different buying problem from phones or cameras

A dashcam is not a camera that occasionally writes a file. It is a device that writes continuously for as long as the vehicle is powered, overwrites the oldest footage in a loop, and is expected to survive the vehicle’s electrical environment — ignition transients, cold-crank voltage dips, and an unswitched accessory socket that may cut power mid-write. The card is the component that absorbs all of that.

Three consequences follow, and they drive everything else in this guide:

1. Write volume, not read speed, is the constraint. A dashcam may write tens of gigabytes per week per vehicle. The card’s endurance is consumed by writes, and loop recording means the same physical cells are rewritten far more often than the file count suggests.
2. Power can disappear at any moment. Ignition-off, hardwired kit timers, and battery-protection cutoffs all remove power without warning. Cards that handle an interrupted write gracefully lose the last few seconds; cards that do not can lose the file system.
3. The camera’s firmware, not the card’s spec sheet, decides what works. Many dashcam SoCs support only a narrow set of file systems, cluster sizes and bus modes. A card that is excellent in a phone can be rejected outright by a camera.

For the electrical and thermal side of this — why a card drops frames when it gets hot, and what a camera can do about it — see our existing article on why dashcam microSD cards drop frames when they get hot. This guide stays on the procurement side.

The numbered checks

1. Confirm the file system the camera actually supports, before choosing capacity

This is the check that most often gets skipped, and it is the one that invalidates the most orders.

FAT32 cannot hold a single file larger than 4 GB and, in its common implementations, is not intended for volumes above 32 GB. exFAT was designed for flash media and large volumes and has no practical per-file limit at dashcam scale. Microsoft documents both limits directly in its file system comparison and exFAT specification pages (see Sources).

What that means in practice:

• A camera that only mounts FAT32 will not reliably use a 64 GB or 128 GB card, even if the card is genuine and correctly formatted. Some cameras will mount a larger FAT32 volume created with a third-party tool, but that is a firmware-dependent workaround, not a specification.
• A camera that supports exFAT can use the larger bands, and the larger bands reduce how quickly the loop overwrites the footage you might need after an incident.
• A camera that supports only FAT32 and records long clips will split files at the 4 GB boundary. That is normal, but it affects how you search footage later and how the camera’s file-naming behaves.

Action: get the camera vendor’s supported file system and maximum tested capacity in writing. Do not infer it from the card slot’s physical size — a microSD slot accepts any capacity the firmware was written to handle.

2. Pick the capacity band from retention requirement, not from the biggest number on the shelf

The right question is not “how much can I buy” but “how many hours of footage must survive before the loop overwrites them, at this camera’s bitrate, across the fleet’s duty cycle”.

Rough sizing logic (Illustrative only — not WINTEL data): a camera recording at a modest bitrate produces on the order of a few gigabytes per hour of driving. A vehicle driven eight hours a day will therefore write tens of gigabytes per week. If the retention policy is “keep the last three days”, a 32 GB card may be marginal and a 64 GB card comfortable; if the policy is “keep the last shift”, 32 GB may be entirely adequate.

Two counterweights keep buyers from over-specifying:

• Larger cards cost more per unit and per fleet, and the incremental footage is only valuable if someone actually retrieves it.
• A larger card concentrates more loss when it fails. If a card dies, the whole retention window goes with it. Smaller cards fail “smaller”, and a mixed fleet can rotate them.

Where the capacity bands stop making economic sense at all is covered in capacity bands: where they stop making sense — worth reading before you assume 256 GB is the safe answer.

3. Match the speed class to the camera’s write pattern, not to the marketing tier

Speed class markings are defined by the SD Association and describe a minimum sustained write performance: the original Speed Class (Class 2/4/6/10), UHS Speed Class (U1/U3), and Video Speed Class (V10 through V90). Application Performance Class (A1/A2) describes random read/write IOPS for app-hosting use, which is largely irrelevant to a dashcam’s sequential write pattern.

For dashcams the relevant question is: what sustained sequential write rate does the camera’s recording profile demand, and does the card hold that rate across the whole card, at temperature, for the life of the card? A card that hits its class rating when new and empty may not hold it when nearly full and warm.

Practical rules:

• Buy at or above the class the camera vendor specifies. Buying below it is how frame drops happen.
• Do not pay for a much higher class than the camera’s bus can use. A camera limited to a slower bus will not benefit from a card rated far above it, and the premium is wasted across a fleet.
• Ask the supplier how the class rating behaves at high fill level and at the fleet’s operating temperature range. This is the question that separates a serious offer from a catalogue copy.

The relationship between A1/A2 markings and real device behaviour is covered in microSD A1 vs A2 application performance; the short version is that A-class ratings do not tell you what a dashcam needs to know.

4. Ask for an endurance figure in writing, and treat “high endurance” as a claim to verify

Continuous loop recording is the wear case that removable cards are least designed for. A phone card might see a few gigabytes of writes per week; a dashcam card in a working vehicle can see that per hour.

There is no universal, mandatory label for endurance on consumer microSD packaging. Suppliers who understand the segment will quote a write-cycle rating, a TBW figure, or a stated warranty period tied to surveillance/dashcam use. Suppliers who do not will say “high endurance” and change the subject.

Action: require the endurance basis in writing, in the quotation, not in a brochure. If the supplier cannot state one, that is a real gap — it means you cannot compare their card to an alternative on the axis that matters most.

5. Lock the controller and flash pairing in the approved-sample record

Two cards with the same capacity, class marking and packaging can behave very differently if the controller or the flash differs. Controllers differ in how they handle bad blocks, how aggressively they do wear levelling, and how they behave when power is cut mid-write. Flash differs in endurance and in how it behaves at temperature.

The pairing matters more than either part alone — see flash brand and controller pairing for why a good controller with mismatched flash can underperform a more modest but well-matched combination.

Action: the approved sample record for a dashcam fleet order should name, at minimum, the controller family, the flash vendor and grade, and the firmware/configuration version. Any substitution should require a new sample approval, not a notification. Our article on flash memory lot traceability and die marking explains what you can and cannot verify from the marking alone.

6. Decide how the cards ship — blank, formatted, or pre-configured

Dashcam fleets often want cards that work the moment they are inserted, which means they must arrive formatted in the file system the camera expects, with the cluster size the camera handles best, and — if the camera writes a folder structure — ideally with that structure already present.

This is a configuration decision, not a manufacturing one, but it has to be specified before the order is placed:

• File system as shipped (FAT32 vs exFAT) and cluster size.
• Volume label, which some fleet management tools use to identify a card.
• Any pre-created folders the camera expects.
• Whether the cards are individually tested after formatting, which matters because a card that passes a bare format can still fail a full-surface write.

Pre-loading content onto removable media is a routine service in this industry; our article on preloading software on custom USB drives covers the workflow questions (hashing, version control, test-after-copy) that apply equally to formatted cards.

7. Specify the marking and packaging so field replacement is unambiguous

In a fleet, cards get swapped between vehicles, handed to drivers, and returned in bulk. If every card looks identical, you cannot tell a card that has been in service for two years from one that came out of the box last week.

Specify:

• Printed marking on the card label: at minimum a fleet part number, and ideally a lot code that maps back to the shipment.
• Packaging that survives field handling — individual sleeves or a multi-pack that a workshop can hand out without repacking.
• A return/rotation scheme so worn cards are removed from service rather than recycled into another vehicle.

Marking and packaging changes are cheap at the order stage and expensive to retrofit. If your fleet also uses branded promotional media, the artwork constraints in artwork formats we accept and the ones that cost time apply to card labels as well.

8. Run a sample acceptance test that reproduces the dashcam workload

A sample that passes a quick format and a 1 GB copy test tells you almost nothing about dashcam suitability. The acceptance test should reproduce the workload:

1. Full-surface capacity verification — write and read back the entire address space, not just a spot check. This is the check that catches counterfeit or downgraded capacity.
2. Sustained sequential write soak — write continuously for long enough to fill the card at least once and observe whether the write rate holds or collapses as the card fills.
3. Interrupted-write test — cut power mid-write repeatedly and confirm the file system survives and the camera’s recovery behaviour is acceptable.
4. Temperature soak — run the write soak at the upper end of the fleet’s operating temperature range, since thermal throttling is a common cause of dashcam frame drops.
5. Camera-in-the-loop test — the only test that proves the combination works is the actual camera model, with the actual firmware, recording for a full duty cycle.

Our sample acceptance checklist covers the generic steps; add the dashcam-specific items above on top.

9. Write the certificate of conformance fields into the contract

The certificate of conformance is the document that lets incoming inspection compare a shipment against the approved sample. For a dashcam fleet order it should carry, at minimum:

• Capacity and file system as shipped.
• Speed class marking as printed.
• Controller family and flash vendor/grade (or the supplier’s stated basis if they will not disclose the vendor).
• Firmware/configuration version.
• The test performed on the lot and the result.

What a certificate of conformance can and cannot tell you is covered in certificate of conformance: what it says. The short version is that it is only useful if the fields were agreed before the order, not after.

10. Plan the replenishment cycle before the first shipment arrives

Dashcam cards are consumables in a way that other flash products are not. A fleet that buys once and never plans a replacement cycle will discover the problem as a wave of failures rather than a scheduled rotation.

Decide in advance:

• Service life assumption per card, based on the endurance figure you obtained in check 4 and the fleet’s duty cycle.
• Rotation interval and who is responsible for pulling worn cards.
• Replacement order size and whether it is bundled with new vehicle commissioning.
• A failure-return process so failed cards come back for analysis rather than being binned.

The purchase-order checklist for a dashcam fleet order

The checks above translate into a set of items that should be settled before the PO is raised. Each item below is a decision to record, not a blank to fill in later.

1. Camera model and firmware version, confirmed in writing. The camera vendor’s stated supported file system, maximum tested capacity and required speed class are the specification the order is bought against. Record the firmware version, because a camera firmware update can change what the card slot accepts.
2. Capacity band, justified by retention requirement. State the retention policy and the duty cycle that produced the chosen capacity, so a later reviewer can see why 32 GB or 64 GB was chosen rather than guessed.
3. File system and cluster size as shipped. Specify FAT32 or exFAT explicitly, and the cluster size, and confirm the camera mounts that configuration in the sample test.
4. Speed class, at or above the camera vendor’s requirement. Record the class and the basis for choosing it, including any statement from the supplier about performance at high fill level and at the fleet’s operating temperature.
5. Endurance basis, in writing. The supplier’s stated endurance figure, write-cycle rating or warranty terms tied to dashcam use, quoted in the offer rather than in a brochure.
6. Controller family and flash vendor/grade in the approved-sample record. Named parts, with a substitution policy that requires new sample approval.
7. Marking and packaging specified. Fleet part number and lot code on the card label; packaging that survives workshop handling.
8. Sample acceptance test scope agreed. Full-surface verification, sustained write soak, interrupted-write test, temperature soak, and camera-in-the-loop recording — with pass criteria written down before the sample is sent.
9. Certificate of conformance fields agreed. The list in check 9, confirmed as the fields the supplier will populate on every shipment.
10. Replenishment and rotation plan. Service life assumption, rotation interval, replacement order size, and the failure-return process.

If the order is large enough that the commercial terms need their own review, the payment-schedule questions in how much deposit and payment schedules work and the timing questions in how long a custom microSD order takes are worth reading before the PO is issued.

What the equipment will and will not accept

A short summary of the compatibility boundaries that most often cause a fleet order to fail in the field:

Constraint	What it rules out	Where it comes from
FAT32-only camera firmware	Volumes above 32 GB without workarounds; single files above 4 GB	Microsoft file system comparison and exFAT specification
Camera bus limited to a slower mode	Benefit from a much higher speed class	SD Association bus-mode definitions
Camera firmware tested only to a stated capacity	Cards above that capacity, even if genuine	Camera vendor documentation
No published endurance figure	Any claim that a card is suitable for continuous recording	Supplier disclosure
No camera-in-the-loop test	Any assurance that the card and camera work together	Acceptance testing

The last row is the one to take most seriously. Every other row can be checked against a document; the last row can only be checked by recording with the actual camera.

Where WINTEL fits

WINTEL (Shenzhen Wintel Digital Technology Limited) manufactures custom TF/microSD cards, USB flash drives, UDP modules and semi-finished boards for OEM/ODM buyers. For dashcam fleet buyers, the relevant starting points are the TF card product page and the semi-finished board page, and the quote request form is where a specification like the one above should be sent.

Two things to be clear about, because they are the questions dashcam buyers ask first:

• Endurance, speed class and temperature figures for a specific WINTEL card are quoted per order against the confirmed specification. They are not published as a catalogue default, and this guide does not state them.
• The file system, marking, packaging and test scope are agreed at quotation, which is why the checklist above is worth completing before the quote request rather than after.

If the fleet order is part of a broader programme — vehicle commissioning, driver equipment, or branded media for a launch — the sizing questions in how much do 500 custom USB drives cost and the MOQ mechanics in custom flash MOQ: where the number comes from apply to the card line as well.

FAQ

Does a dashcam need an “endurance” or “high-endurance” microSD card? A dashcam writes continuously whenever the ignition is on, so the card sees far more program/erase cycles per year than a phone card. Cards marketed for high-endurance or surveillance use are built with that write profile in mind. Whether a specific card is suitable depends on the manufacturer’s published endurance figure — ask for it in writing rather than relying on the label alone.

Should I standardise on 32 GB, 64 GB or 128 GB for a fleet? It depends on how long the camera must retain footage and how the camera handles loop recording. Cameras that only support FAT32 cannot use volumes above 32 GB without workarounds, so 32 GB is the safe ceiling there. Cameras that support exFAT can use 64 GB and above, which reduces how often old footage is overwritten but increases per-unit cost and the amount of data lost if a card fails.

Can I use the same card in dashcams and in the fleet’s handheld terminals? Only if both devices accept the same file system, capacity and speed class. Mixing roles also mixes write profiles — a card pulled from a 24/7 dashcam and dropped into a handheld will have far more wear than the handheld expects. Keep separate stock lines and separate part numbers.

What should I ask the supplier to put in the certificate of conformance? Capacity, file system as shipped, speed class marking, controller and flash vendor/lot where the supplier can disclose it, firmware/configuration version, and the test performed on the sample lot. Ask for the same fields on every shipment so incoming inspection can compare against the approved sample.

How do I avoid cards that report the wrong capacity? Test a sample from every lot with a capacity-verification tool that writes and reads back the full address space, not just a quick format. Counterfeit or downgraded cards typically show up as write failures or read-back mismatches beyond the real die capacity. Make full-surface verification part of the sample acceptance step, not just the first order.

Sources

• SD Association — SD Specifications, Speed Class and Application Performance Class: https://www.sdcard.org/developers/sd-standard-overview/ (accessed 2026-10-30)
• SD Association — SD Memory Card Formatter: https://www.sdcard.org/downloads/formatter/ (accessed 2026-10-30)
• Microsoft Learn — exFAT file system specification: https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification (accessed 2026-10-30)
• Microsoft Learn — File system functionality comparison (FAT32 limits): https://learn.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison (accessed 2026-10-30)
• Linux kernel documentation — MMC/SD subsystem: https://docs.kernel.org/driver-api/mmc/index.html (accessed 2026-10-30)
• JEDEC — Standards and documents (managed NAND / endurance background): https://www.jedec.org/standards-documents (accessed 2026-10-30)