What Is a Chromebook? ChromeOS Devices Explained for Schools

A Chromebook signs the user in with a Google account and rebuilds their working environment from that account: browser profile, bookmarks, extensions, policies and cloud files. Because the environment follows the account rather than living on the machine, any managed device in the building becomes that student's device the moment they sign in — which is why shared-cart and one-to-one models both work on the same hardware without re-imaging between them.

The applications are mostly web applications. A full productivity suite, a learning management system, a student information system and most classroom tools run in the browser, and progressive web apps can be installed so they open in their own window and appear in the launcher like native software. Many Chromebooks can additionally run Android applications from the Google Play Store, and ChromeOS includes an optional Linux development environment for computer-science coursework — both of which extend what the platform can do beyond the browser, though neither turns it into a general-purpose desktop.

Local storage exists but is deliberately small and secondary. Files saved to the device sit in a downloads area and are encrypted; the expectation is that work lives in cloud storage and syncs. That design is what makes a broken Chromebook a hardware problem rather than a data problem — a replacement device signed into the same account restores the user's working state without a backup or restore process.

Four architectural decisions do most of the work, and Google documents all of them. The first is verified boot: Google describes ChromeOS as completing a self-check every time the device powers on, and states that if unfamiliar code is detected the system automatically repairs itself by reverting to a previous version. The check begins in a read-only portion of firmware and validates each subsequent stage before executing it, so a compromised system partition is detected rather than trusted.

The second is the read-only operating system. Google's own framing is that as a read-only operating system, ChromeOS cannot run executable files — the traditional delivery vehicle for viruses and ransomware — so a malicious executable that reaches the device has nowhere to install itself. The third is sandboxing: threats are contained to the specific tab or application they arrive in, so a compromised page does not become a compromised machine. The fourth is the update model. Updates download in the background and apply on the next restart, and they cover the operating system, the browser and hardware components together rather than arriving as separate patch streams an administrator has to sequence.

The practical difference for a school is what these remove from the workload. There is no image to build and maintain, no antivirus agent to license and update, no monthly patch window to schedule around instruction, and no local administrator account to worry about. What replaces that work is policy management in a console, which is a smaller and more predictable job — but it is not zero, and it is licensed separately, which the next section covers.

Yes, but only for what has been prepared in advance. Google's productivity applications offer an offline mode that has to be enabled while the device is still connected, after which recently used documents are cached locally and edits sync when the connection returns. Mail can be read and composed offline in the same way, and files explicitly marked for offline availability in cloud storage are held on the device. Downloaded media, locally installed Android apps and the Linux environment all continue to work without a network.

What does not survive an outage is anything that was not cached ahead of time: a document the student has never opened, a web-based assessment platform, a live collaboration session, a video lesson streamed rather than downloaded. For a district that sends devices home into households with unreliable connectivity, the honest planning assumption is that offline mode is a bridge across an interruption rather than a way to run a curriculum disconnected. Teach staff to enable offline availability on the material a student will need, and treat that as part of the deployment procedure, not as a user preference.

This is also where the difference between a Chromebook and a thin client matters. A thin client is useless without a network because the session itself lives on a server. A Chromebook is a complete computer that degrades to a smaller feature set when the network disappears — a meaningful distinction when specifying devices for take-home programs or for buildings with patchy wireless coverage.

Management happens in the Google Admin console, and it requires a license. Google states that to manage standalone ChromeOS devices in your organization you need a ChromeOS Enterprise Upgrade, a ChromeOS Education Upgrade or a Kiosk and Signage Upgrade — or a device that came with one of those bundled. Without an upgrade the hardware is a consumer Chromebook: it works, but it cannot be enrolled, policy-managed, force-installed to, or remotely disabled.

Once a device is enrolled, the console applies device and user policies together. Google documents enforcing settings on managed devices, configuring Wi-Fi and proxy settings, automatically installing apps and extensions, limiting access to authorized users only, applying different settings to different groups such as teachers versus students, dedicating devices as purpose-built kiosk apps, and controlling managed guest sessions that people share without an account. In an education deployment that is the whole management surface: organizational units per school or grade band, a policy set per unit, and enrollment handled at receipt.

Two licenses are commonly confused here and they do different jobs. The device upgrade licenses the machine and makes it manageable. Google Workspace for Education editions license the user and determine what that person's account can do. A district needs to make both decisions, and they are scoped differently — one by device count, one by headcount.

The clearest limit is software that ships as a Windows or macOS installer. Full computer-aided design packages, the desktop versions of professional creative suites, engineering and statistics software, industry-specific career and technical education applications, and any vendor tool distributed as an installer will not run on ChromeOS. Web versions sometimes exist and are sometimes adequate, but a CTE program built around a specific desktop application needs Windows workstations, not Chromebooks, and pretending otherwise produces a lab that cannot teach its own curriculum.

Peripherals are the second constraint. Devices that depend on vendor drivers — some scientific instruments, specialized scanners, certain graphics tablets, older printers and lab interfaces — may have no ChromeOS support at all. Verify each peripheral against the platform before committing a room, because a driver that does not exist cannot be worked around.

Assessment is the third, and it is the one most likely to cause a scramble in the spring. Some testing platforms ship a ChromeOS kiosk application and are fully supported; others require a locked-down secure browser that only exists for Windows or macOS. Which of those applies is a vendor-by-vendor fact and it changes between versions, so confirm it against your specific assessment stack — including any state-mandated platform — before you standardize a grade band on Chromebooks. Finally, sustained heavy local work such as long-form video editing or large local datasets is a poor fit on a platform designed around modest local storage and cloud-resident files.

Start with the auto update expiration date, because it is the specification that determines how long the device can safely stay in service. Google provides ten years of automatic updates measured from the platform's release date rather than from your purchase date, which means an older platform bought new can have far less usable life left than a newer one at a similar price. Check the date before you compare anything else; it reorders the shortlist more often than any other number.

Then match the hardware to the user. Memory and storage are the two specifications districts most often under-buy — a student who keeps twenty tabs open on four gigabytes of memory has a slow device regardless of the processor. Screen size and whether it needs to be touch-enabled or convertible depend on grade band; ruggedization, spill resistance and reinforced ports matter enormously in elementary deployments and less in a staff device. A comfortable keyboard matters more than a benchmark for anyone writing all day.

Finally, plan the things that are not the device. Accidental damage protection and a realistic spare ratio are what keep a one-to-one program running, because the failure rate in student hands is a schedule, not an accident. Charging carts, labeling, asset tagging and enrollment at receipt all belong in the same order rather than in a later requisition. And decide the licensing at purchase time: a device bundled with a management upgrade arrives ready to enroll, whereas a device bought without one is a consumer machine until a license is attached to it.