Teacher Accounts Are Full Accounts
Teachers who use Blooket to build question sets and host games need a full account, created with either an email and password or a connected provider such as Google. This account persists across sessions, storing saved question sets, hosting history, and account settings. Because the account is tied to ongoing use, logging in is a repeatable step, and password recovery, connected provider sign in, and standard account security features all apply the same way they would for any other web service.
This also means teacher accounts benefit from the same login hygiene as other tools, including using a unique password if not signing in through a connected provider, and being cautious about which devices remain signed in, particularly on shared or public computers.
Students Typically Do Not Need an Account
Students joining a live game do not go through the same login process at all. Instead, they use a separate join page, enter the game code provided by the teacher for that specific session, and choose a display name. No email, password, or persistent account is required for this path. The design intentionally avoids account creation for students, both to lower the barrier to entry for younger users and to reduce the amount of personal information the platform needs to collect from minors.
This distinction matters for troubleshooting too. If a student reports a login problem, the fix is almost never a password reset, since there is no password involved. Instead, issues in this path usually trace back to an incorrect or expired game code, a typo in the code field, or a connectivity issue on the student's device.
When Students Might Need an Account
There are a few situations where a student facing account becomes relevant, mainly around self paced assignments that need to track individual progress over time rather than a single live session. In these cases, some form of lightweight identification tied to a class roster may be used, but this is still distinct from the full email and password account structure used by teachers, and it does not require students to manage a traditional login themselves.
Why the Systems Are Separate
The two tracks solve different problems. Teachers need persistent access to content they create and reuse across many class periods, which justifies a full account. Students need frictionless, low barrier access to a single session that typically lasts only a few minutes, which makes a lightweight, code based join process a better fit than requiring an account. Building both around the same heavier login system would add unnecessary friction for the far more frequent and short lived student use case.
Frequently Asked Questions
Can a student create a full account if they want to? Some setups allow it, generally tied to a school's broader identity management, but it is not required for standard participation in live games.
What happens if a student loses their game code? Since no account is tied to a single game session, the fix is simply getting the correct code again from the teacher rather than any kind of account recovery.
Do teachers ever use the code based join system instead of logging in? No. Hosting a game requires a full teacher account, since hosting controls, saved sets, and class management all depend on persistent account data.
Is student information collected during the code based join process? The process is designed to minimize data collection, generally requiring only a temporary display name for that session rather than any personal account details.
Can a teacher see which students joined a session without accounts? Yes. The host view during a live game shows the display names of everyone who joined using the code, along with their performance, even though those participants never created an account.
