What microSD Card Should I Buy for Education Tablets and E-Readers?

TL;DR

For education tablets and e-readers, buy 32 GB SDHC cards formatted FAT32 as the default, and only move to 64 GB or 128 GB SDXC (exFAT) after you have confirmed on the exact device model and firmware that exFAT is mounted natively. Speed class matters less than capacity honesty and file-system compatibility: Class 10 / U1 is the practical floor, A1 is enough unless the OS runs apps from the card, and A2 is only worth paying for in that specific case. Lock the card in the BOM by capacity, file system, speed class, controller family, and a capacity-verification test, and put those five items on the purchase order — not just “microSD 64 GB”.

This guide covers the segment-specific decisions a procurement lead, IT manager or OEM buyer has to make for education tablets and e-readers. For the underlying technical background, the linked articles go deeper than this page will.

Why this segment is different from dashcams or IoT

Education tablets and e-readers are read-mostly, write-light devices. A student opens a PDF, an EPUB, a video lecture or an offline learning app; the card is read many times and written rarely. That is the opposite of a dashcam, which overwrites the card continuously and where endurance is the limiting factor.

Three consequences follow:

1. Endurance is rarely the constraint. A card that would fail in a dashcam inside a year can serve a reader for its whole service life. Do not overpay for high-endurance media unless the deployment writes heavily (for example, a note-taking tablet that saves annotations locally).
2. Capacity honesty is the real risk. Because the card is used as a content library, a counterfeit “256 GB” card that is actually 8 GB will silently corrupt a whole booklist. Capacity verification belongs on the PO.
3. File-system compatibility is the most common field failure. A perfectly good 64 GB card that the reader cannot mount is worse than a 32 GB card that works. This is a BOM decision, not a support ticket.

The two buying guides that cover the opposite ends of the write-intensity spectrum are /blog/microsd-cards-for-dashcams-buying-guide and /blog/microsd-cards-for-iot-data-logging-buying-guide; this page links to them rather than repeating the endurance math.

The capacity band that actually fits

The SD Association’s standard splits cards at 32 GB: up to and including 32 GB is SDHC, above 32 GB is SDXC, and SDXC cards ship formatted as exFAT by default. That single line drives most of the compatibility decisions in this segment.

Band	Standard	Default file system	Typical fit in education / e-readers
8–16 GB	SDHC	FAT32	Single-subject readers, primary-school tablets, cheap throwaway cards
32 GB	SDHC	FAT32	Default fleet standard — widest device compatibility
64 GB	SDXC	exFAT	Secondary/high-school tablets, large EPUB/PDF libraries, only if exFAT confirmed
128 GB	SDXC	exFAT	Reference libraries, offline video courses, medical/technical readers
256 GB+	SDXC	exFAT	Rarely justified; check the device’s documented maximum first

The general rule for where capacity bands stop being economical is covered in /blog/capacity-bands-where-they-stop-making-sense. For this segment specifically, the decision tree is:

• Does the device documentation list a maximum card size? If it says 32 GB, do not standardize on 64 GB “because it’s cheap”. You will create a support queue.
• Does the OS mount exFAT natively? Android has supported exFAT through the kernel for many versions, but vendor builds vary; some readers use stripped-down firmware. Test on the exact model and firmware revision you are deploying.
• Will any single file exceed 4 GB? FAT32 caps individual files at 4 GB (Microsoft’s own documentation is explicit about this). A single PDF or EPUB will not come close; a full video course might. If you need 4 GB+ files on a 32 GB card, that is a signal to move to 64 GB SDXC and confirm exFAT.
• Is the card also used for personal files by students? If yes, capacity headroom matters more than in a locked-down deployment.

File system: the decision that causes the most returns

There are only three realistic choices in this segment, and each has a specific failure mode.

FAT32 — the safe default

FAT32 is the only file system that every education tablet, e-reader and legacy Chromebook in the field is guaranteed to mount. Its limits are real: 4 GB maximum per file, and Microsoft’s own guidance has historically capped FAT32 formatting at 32 GB even though the filesystem itself supports more. For a 32 GB SDHC card holding EPUBs, PDFs, MP3s and sub-4 GB videos, none of that matters.

The trade-off is that FAT32 has no journaling and no atomic rename. If a student yanks the card mid-write during a firmware update or a save, the directory entry can be left inconsistent. The mitigation is operational: instruct users to unmount before removal, and keep any critical writes (firmware, provisioning) on internal storage where possible. The mechanism is explained in /blog/microsd-card-power-loss-corruption-and-what-protects-data.

exFAT — the choice for 64 GB and above

exFAT is what SDXC cards ship with, and Microsoft’s specification describes it as designed for flash media with large volumes and large files. It removes the 4 GB per-file limit and is the correct choice for a 64 GB or 128 GB card holding video courses or a large reference library.

The catch is device support. Any device that only ships a FAT32 driver will show the card as unreadable. On iPadOS, external storage access is mediated by the Files app and per-app directory permissions rather than raw block access (see Apple’s developer documentation on directory access); on Linux-based readers, the mount behaviour depends entirely on the kernel configuration the vendor shipped (see the Linux MMC/SD subsystem docs). Neither of those is something you can assume — you have to test.

A single partition, not two

Some buyers ask for a small FAT32 partition for configuration and a large exFAT partition for content. Resist this unless a specific application requires it. Many consumer devices only mount the first partition they find, and support cost goes up sharply. If you genuinely need a config area, put it on internal storage.

Speed class: what to specify and what to skip

The SD Association defines three families of speed marking that matter here: the original Speed Class (Class 2/4/6/10, based on sustained sequential write), UHS Speed Class (U1/U3), and Video Speed Class (V6–V90). Separately, Application Performance Class A1/A2 describes random read/write IOPS for running apps from the card.

For education tablets and e-readers:

• Class 10 / U1 is the practical floor. It is cheap, universally supported, and adequate for reading EPUBs and PDFs and for sequential playback of standard video.
• U3 / V30 is unnecessary unless the device records video to the card (a small number of note-taking tablets do). Paying for V30 on a reader wastes money.
• A1 is worth specifying if the OS installs any apps to the card. A2 is only worth paying for if the deployment actually runs apps from removable storage at scale; the difference between A1 and A2 is explained in /blog/microsd-a1-a2-application-performance.
• Random read matters more than sequential write for an e-reader opening a large EPUB library. This is not captured by any SD Association speed class; it is a controller and NAND characteristic. Ask the supplier what controller family they use and how they test random read, rather than relying on the class logo.

What the device will and will not accept

Before you write the BOM, confirm these five things against the exact device model and firmware revision:

1. Maximum card size documented by the OEM. A device that says “up to 32 GB” will often work with 64 GB, but “often” is not a procurement strategy.
2. File systems mounted by the kernel or firmware. Confirm FAT32, exFAT, or both. On Android, check the vendor’s storage documentation; on Linux readers, check whether the exFAT kernel module is present.
3. Whether the slot is SDHC-only or SDXC-capable. Physical compatibility is the same; the controller and driver are not.
4. Whether the device writes to the card at all. Some managed tablets mount the card read-only. If so, endurance and write performance are irrelevant, and the only things to specify are capacity, file system and capacity honesty.
5. Whether the device re-formats the card on first insert. A few managed-device configurations wipe and re-format removable storage. If yours does, pre-loading content is pointless and you should not pay for it.

For the wider question of where a card stops being the right answer and an embedded eMMC or a soldered module starts, the comparison is in /blog/microsd-card-vs-embedded-emmc-which-storage-for-portable-devices. For education tablets specifically, the card slot is usually there for cost and field-replaceability, not for performance — which is exactly why the BOM should optimize for compatibility and honesty rather than for speed class.

What to lock in the BOM

A microSD line in a BOM that just says “microSD 64 GB” is not a specification; it is an invitation to substitution. Lock these five attributes, and require the supplier to confirm each one in writing:

Attribute	What to write	Why it matters
Capacity and standard	“64 GB, SDXC” or “32 GB, SDHC”	Fixes the file system default and the device-compatibility envelope
File system at shipment	“Pre-formatted exFAT” or “Pre-formatted FAT32”	Prevents the most common field failure
Speed class	“Class 10 / U1” or “A1”	Prevents substitution with a slower or mislabeled part
Controller family	Named controller family or vendor	Random read performance and capacity honesty depend on it
Capacity verification	Method and pass criterion	Catches counterfeit or under-provisioned cards before they ship

Two further items belong in the BOM for this segment even though they are not card attributes:

• Marking and packaging. If cards are handed to students, individual labeling and packaging matter. The rules for variable data (serial numbers, student IDs) are in /blog/different-names-on-each-unit-variable-data.
• Content pre-loading, if used. Specify the manifest format, checksum method and rejection criteria. Do not leave this to a verbal agreement.

A purchase-order checklist for education and e-reader deployments

The following is a numbered set of checks to work through before the PO is issued. Each one exists because skipping it has a known failure mode in this segment.

1. Confirm the device model, firmware revision and documented maximum card size in writing from the OEM or IT owner. This is the single input that decides everything else. A “32 GB max” device and a “1 TB max” device need different BOMs.

2. Confirm which file systems the device mounts natively, on a physical unit, not from a datasheet. Format one card as FAT32 and one as exFAT, insert both, and record what the device shows. Keep the test record with the PO.

3. Choose the capacity band from the compatibility result, not from the price list. If 32 GB works everywhere, standardize on 32 GB even if 64 GB is a few cents more per unit. The support cost of a single incompatible card in a school is larger than the saving across a fleet.

4. Specify the speed class explicitly on the PO. “Class 10 / U1” or “A1” as appropriate. Do not leave the class unstated — the supplier will ship whatever is cheapest that day.

5. Specify the controller family and require the supplier to confirm it in writing. This is what protects random read performance for large EPUB and PDF libraries, and it is the item most often quietly substituted between sample and mass production.

6. Specify a capacity verification method and pass criterion. At minimum, a full-capacity write-and-verify test on a sample from each production lot, with the result reported per lot. The reasoning and the tools are covered in /blog/fake-usb-drive-capacity-how-to-check.

7. Decide whether content pre-loading is required, and if so, specify the manifest and checksum. If it is required, define what happens to a card that fails the post-write checksum: is it reworked, scrapped, or shipped with a note? The answer belongs on the PO.

8. Decide the file system at shipment and write it on the PO. “Pre-formatted FAT32” or “Pre-formatted exFAT”. Do not leave it to the supplier’s default, which may differ between lots.

9. Specify labeling and packaging if cards are distributed individually. Student ID, asset tag, or a plain logo. Confirm the artwork format early; the formats that cost time are covered in /blog/artwork-formats-we-accept-and-the-ones-that-cost-time.

10. Agree the sample acceptance criteria before the sample is made. What will you test, on what device, with what pass criterion, and how many units? A sample that is not tested against the real device is not an acceptance test. The checklist at /tools/sample-acceptance-checklist is a reasonable starting point.

11. Agree the lot traceability requirement. For a school fleet that will be supported for years, being able to trace a failed card back to a production lot matters. The relevant background is in /blog/flash-memory-lot-traceability-and-die-marking.

12. Agree the delivery schedule against the actual school-term date, not against a generic lead time. Working back from a fixed date is a different exercise from quoting a lead time; the method is in /blog/i-need-these-by-the-15th-working-back-from-a-date.

13. Agree what happens if the device OEM changes the firmware mid-deployment. A firmware update can change exFAT support, mount behaviour, or the maximum card size. Build a re-test step into the deployment plan and a re-qualification trigger into the supply agreement.

14. Agree the currency and price-validity clause. Flash prices move; a PO that assumes a six-month price hold without a clause is a PO that will be renegotiated. The mechanics are in /blog/currency-clauses-two-places-price-moves.

Where WINTEL fits, and where it does not

WINTEL (Shenzhen Wintel Digital Technology Limited) manufactures custom TF/microSD cards, USB flash drives, UDP modules and semi-finished boards for OEM/ODM buyers. The company’s confirmed capabilities include:

• Custom TF/microSD card manufacturing, alongside USB drives, UDP modules and semi-finished boards.
• A 5,000 m² factory, 200+ employees, and a stated monthly capacity of 500,000+ units.
• Certifications listed as SGS, RoHS, CE and FCC.
• Export to 50+ countries.
• Business contact: Cathy, cathy@go-wintel.com, +86-132 2685 1179.

What this guide does not claim on WINTEL’s behalf: specific speed classes, endurance or TBW figures, operating temperature ranges, minimum order quantities, lead times, test results, customer cases, or certifications beyond the four listed above. Those are questions to put to the supplier directly, and the answers should appear on the quotation and the PO.

For the education and e-reader segment, the parts of the WINTEL range that are relevant are the custom TF/microSD card line (see /products/tf-card) and, for buyers evaluating whether a card slot is the right architecture at all, the semi-finished board line (see /products/semi-finished). To start a quotation with the attributes above already specified, use /request-a-quote.

Worked example: sizing a 500-tablet deployment (Illustrative only — not WINTEL data)

To make the checklist concrete, here is a hypothetical sizing exercise. Every number below is illustrative and is not WINTEL data.

A school is deploying 500 Android tablets for lower-secondary students. The OEM documents a 32 GB maximum card size and FAT32 only. The content library is 18 GB of EPUBs, PDFs and MP3s, with no file over 200 MB.

• Capacity: 32 GB SDHC, FAT32. The 18 GB library fits with 14 GB headroom for student work and future content.
• Speed class: Class 10 / U1, A1 if the OS installs apps to the card. U3 is not justified.
• Controller: specified by family, with a random-read test on a sample.
• Capacity verification: full write-and-verify on 10 cards from each production lot; pass criterion is zero short-writes.
• Pre-loading: 500 cards, content manifest hashed with SHA-256, post-write checksum verified per card, failures reworked.
• Labeling: student asset tag applied at the factory, with the variable-data rules agreed in advance.

The point of the example is not the numbers; it is that six of the seven lines are decisions a buyer can only make after step 2 of the checklist (confirming what the device mounts). A PO written before that step is a PO written on assumptions.

FAQ

What capacity should I standardize on for a school tablet fleet? Most K–12 and lower-secondary fleets standardize on 32 GB SDHC, because it is the largest capacity that still formats as FAT32 by default and is accepted by the widest range of Android tablets, e-readers and older Chromebooks. Move to 64 GB SDXC only after you have confirmed, on the exact device model and firmware, that exFAT is mounted natively.

Why do some e-readers reject a 64 GB or 128 GB card? Cards above 32 GB are SDXC and ship formatted as exFAT. Devices whose kernel or firmware only includes a FAT32 driver will mount the card as unreadable or blank. The fix is either to reformat the card as FAT32 (which then breaks files over 4 GB) or to specify an SDHC card at the BOM stage.

Do I need A1 or A2 for an education tablet? A1/A2 are application-performance classes defined by the SD Association for running apps from the card. If your deployment only stores PDFs, EPUBs, video and audio, A1 is sufficient and cheaper. Specify A2 only if the OS actually installs and runs apps from removable storage.

Can I pre-load content onto the cards before shipment? Pre-loading is a common request for education deployments. It requires an exact content manifest, a defined file system, a checksum per card, and a re-test step after writing. Confirm the manifest format, checksum method and rejection criteria with your supplier before the order is placed, not after.

Is a cheaper card acceptable for e-readers? E-readers write very little — mostly sideloaded books and firmware updates. Read speed and capacity matter more than endurance. The risk is not wear-out, it is counterfeit capacity and poor random-read performance on large EPUB or PDF libraries. Buy from a supplier that can show a capacity verification method.

Sources

• SD Association — SD Standard Overview (capacity and file system): https://www.sdcard.org/developers/sd-standard-overview/ — supports SDHC/SDXC boundaries and default file systems. Accessed 2026-11-04.
• SD Association — Speed Class: https://www.sdcard.org/developers/sd-standard-overview/speed-class/ — supports definitions of Speed Class, UHS Speed Class, Video Speed Class and Application Performance Class. Accessed 2026-11-04.
• Microsoft Learn — exFAT file system specification: https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification — supports exFAT design intent and size limits. Accessed 2026-11-04.
• Microsoft Support — FAT32 file system description: https://support.microsoft.com/en-us/topic/description-of-the-fat32-file-system-3b1b5f27-1e5d-4d5e-2a9c-9b9f0a4c6e2a — supports the 4 GB per-file limit and 32 GB formatting guidance. Accessed 2026-11-04.
• Apple Developer — Providing access to directories: https://developer.apple.com/documentation/uikit/view_controllers/providing_access_to_directories — supports the app-sandboxed directory model for external storage on iPadOS. Accessed 2026-11-04.
• Linux kernel documentation — MMC/SD subsystem: https://docs.kernel.org/driver-api/mmc/index.html — supports how Linux-based devices enumerate and mount SD cards. Accessed 2026-11-04.
• JEDEC — organisation root: https://www.jedec.org/ — general reliability and endurance framework for NAND-based storage (access date 2026-11-04).