Microsoft Forms system requirements and compatibility
Microsoft Forms is a browser-based survey and quiz service (forms.microsoft.com) for collecting responses and creating quizzes. Most users can open and submit forms with a consumer Microsoft account or a Microsoft 365 license that includes Forms; creating and administering organization-owned forms requires a Microsoft 365 license that enables Forms (or use of Forms for Excel) plus a modern browser with cookies and third-party content allowed for Microsoft domains.
What exactly counts as the Microsoft Forms platform
Definition: When documentation says "Microsoft Forms" it usually means the cloud Forms service at forms.microsoft.com. That full service supports surveys, quizzes, branching logic, response collection, sharing controls and a web admin surface.
Other experiences that share the Forms name:
- Forms for Excel: a form attached to an Excel workbook (OneDrive or SharePoint). It uses a subset of the Forms UI and writes responses as rows in the workbook.
- Forms inside Teams: a simplified authoring and response experience embedded in Teams tabs and chats. It supports basic questions and response collection but lacks some advanced settings and admin controls.
For example, say you need branching logic and response limits: the standalone Forms service supports those features. A form created from inside an Excel workbook may lack some branching or presentation options because the workbook attachment controls how responses are saved.
Boundaries: Forms is a cloud service; you cannot host it on-premises. If a tenant blocks cloud services entirely or runs an environment that disables JavaScript, Forms will not work.
Misconceptions: If a user says they "don’t have Forms," confirm whether they mean the cloud Forms site, a form attached to Excel, or the Teams tab experience. Licensing, storage location and tenant admin policies can allow one experience while blocking another.
Which Microsoft accounts and licenses let you use Forms
Direct answer: consumer Microsoft accounts and many Microsoft 365 subscriptions include Forms, but features and admin controls differ by license.
- Consumer accounts: Outlook.com or Hotmail users can open, submit and create simple forms on the consumer Forms site. Enterprise admin controls and some retention features do not apply.
- Microsoft 365 Business and Enterprise subscriptions: most Business and Enterprise SKUs include the Forms service. Tenant admins can control who can create forms and whether guests can respond. Some enterprise features (for example, advanced data residency controls) depend on your specific plan and tenant policies.
- Education subscriptions: Microsoft 365 for Education includes Forms with quiz/grade features and integrations with Teams for Education; some education-specific controls affect export and assignment flows.
- Guest accounts: guests invited to respond usually can submit responses if the form allows external responses. Creating or administering forms as a guest depends on the host tenant’s policies; many tenants block guest creation.
Features admins can gate: branching (conditional logic), response limits, export options, sharing policies (who can respond) and the tenant-level switch that disables form creation for certain users or groups.
For example: one consumer user, one Business-licensed user and one guest can all submit responses, but only the Business-licensed user (and only if tenant creation rights are enabled) will reliably create and manage organization-owned forms.
Which browsers, OS and devices are supported right now
Direct point: Microsoft Forms runs in modern desktop and mobile browsers and depends on browser features such as ES6, cookies and cross-origin requests. If a browser is several major versions out of date, expect failures when loading the editor or submitting responses.
Supported desktop browsers:
- Chromium-based Microsoft Edge, Google Chrome, Mozilla Firefox and Apple Safari. Use current stable releases; the authoring UI is best supported in Chromium-based browsers.
Supported mobile platforms and browsers:
- iOS: Safari and Chromium-based browsers on iOS open and submit forms. Creating complex forms on a small phone screen is possible but limited by the mobile UI.
- Android: Chrome and Chromium-based browsers support viewing, submitting and simplified form creation.
- Mobile apps: There is no separate full-featured Microsoft Forms mobile app for creators. Office mobile apps and Teams can surface forms but with feature differences.
Device and OS notes:
- Windows and macOS: Keep OS updates and a modern browser. Older OS releases that block browser updates will prevent supported browser versions from running.
- Tablets: Authoring works on tablets but layout and some configuration panes are reduced.
- Legacy browsers: Internet Explorer and IE mode in Edge are not reliable for the full editor; move users to a modern browser for creation and complex editing.
Exact minimum browser version numbers change. For strict compliance needs, check Microsoft’s current product documentation for version requirements.
For example, a user on an old corporate laptop with Internet Explorer or another end-of-life browser will likely be unable to open the full forms editor; give them a supported browser on the same device.
Network, authentication and security settings that commonly block Forms
Point first: Forms needs outbound access to Microsoft cloud endpoints, cookie-based authentication and the ability to load scripts and assets from Microsoft domains. Firewalls, proxies, SSO settings or blocked cookies are the most common causes of failure.
Required network allowances:
- Allow outbound HTTPS (TCP port 443) to Microsoft 365 endpoints used by Forms.
- If you use a proxy or TLS-inspecting appliance, ensure it presents a certificate trusted by clients.
- Permit Azure AD and Microsoft account authentication endpoints used by your sign-in flows.
Authentication and SSO implications:
- Azure AD SSO: Forms uses the same token flows as other Office 365 web apps. Conditional Access policies (MFA, device compliance, location restrictions) apply to Forms the same as to other cloud apps.
- Consumer vs work accounts: Authentication redirects can involve different domains for consumer Microsoft accounts; if you allow both, include both sets of endpoints in your allowlist.
Third-party content and embedded resources:
- Forms loads scripts, fonts and assets from Microsoft domains. Blocking those domains, blocking inline scripts, or denying cross-origin requests will break the editor or form rendering.
- Embedded images or videos that sit on third-party CDNs require those CDNs to be reachable to render properly.
Common proxy/firewall problems to check:
- Blocking auth endpoints, denying third-party cookies needed for SSO, or deploying TLS interception without trusted certificates.
- Content inspection that alters response bodies or strips headers can break the single-page app and token exchanges.
Where it does not apply: purely offline networks or environments that intentionally block all cloud services will not support Forms at all. Forms is not an on-premises product.
When forms behave differently: embedding, Teams, SharePoint and printing
Lead: Embedding a form or using it inside another Microsoft app changes available features and adds requirements.
Embedded forms in SharePoint pages:
- Behavior: Embedded forms render in an iframe and rely on cross-origin resource access. If your tenant or browser blocks third-party cookies or cross-site tracking, the embedded form may not load or may force users to sign in in a separate tab.
- Example: If your organization blocks third-party cookies, users viewing an embedded form on SharePoint may see a blank area or a sign-in prompt that doesn’t complete inside the iframe.
Forms inside Teams:
- Behavior: The Teams tab integration provides a simplified authoring and response experience. Advanced Forms features (detailed branching, some sharing options) may require opening the form in the web Forms experience.
- Requirement: Teams desktop and web clients must be updated. The Teams desktop client uses an embedded browser engine; if script execution or web content is blocked by policy, embedded forms will be affected.
Printing and exporting results:
- Behavior: You can export responses to Excel or print summary charts from the Forms web UI. For forms created from an Excel workbook, responses are already stored in the workbook and export/print behavior follows Excel.
- Limitation: Large response sets or complex question types may not export identically between Forms and Forms for Excel; verify exported schemas if downstream reporting depends on a specific layout.
Restricted environments and legacy browsers (IE mode):
- Internet Explorer and IE mode: The full Forms editor is not guaranteed to work in legacy IE modes. If your users must use IE mode for other legacy apps, instruct them to open forms in a modern browser.
- Kiosks and locked-down browsers: Environments that disable cookies, block JavaScript or restrict cross-origin requests will break Forms. If you must run in a restricted environment, test that exact configuration and provide a direct link for users to open the form in a supported browser if needed.
Quick checklist and simple fixes to try first
Run this ordered checklist when a user "can’t access" or "can’t create" forms. Each step is a quick check you can do before raising a ticket.
- Confirm the user’s account and license.
- Verify the user is signed in with the intended account (work/school vs consumer) and that the tenant allows Forms creation.
- Test sign-in and tenant policy effects.
- Sign out, open a private/incognito window, and sign in again to reproduce errors without cached cookies.
- Try an updated, supported browser.
- Use a current Chromium-based browser or Safari and open
forms.microsoft.com. If the user used Internet Explorer, move them to Edge or Chrome.
- Clear cookies and cache for Microsoft domains.
- Clearing cached auth cookies often resolves intermittent token issues.
- Check network and proxy rules.
- Confirm outbound HTTPS to Microsoft 365 endpoints is permitted and that TLS interception isn’t interfering.
- Confirm third-party cookies and cross-site requests are allowed for Microsoft domains in the browser.
- Reproduce in a different network or device.
- If the form works on a home network or mobile hotspot, the issue is likely network or proxy related.
If Conditional Access or device compliance policies are in place, bypassing them for troubleshooting should be done with approval from your security owners.
- If creation is blocked but response submission works, check tenant admin settings that disable form creation.
- If embedding issues occur in SharePoint or Teams, open the form directly at
forms.microsoft.comto see whether the problem is embedding-specific. - When to escalate: persistent authentication failures after verifying network and browser, tenant-level license inconsistencies you cannot reconcile in the admin center, or service disruptions matching Microsoft service health notices.
Conclusion
To verify readiness across your organization: decide which Forms experience people will use (cloud Forms, Forms for Excel or Teams), confirm licenses and tenant creation policies, and ensure devices run a modern browser with cookies and outbound HTTPS to Microsoft endpoints allowed. Use the checklist to triage issues quickly; escalate to Microsoft support only after you’ve ruled out license, browser and local network causes.
Frequently Asked Questions
Can users on IE11 create and edit forms?
IE11 and legacy browser modes are not a reliable platform for the full Forms authoring experience. Users might open simple forms, but the editor and some features are likely to fail. Recommend a modern browser for creation and editing.
Do guests need a Microsoft account to respond to a form?
It depends on the form’s sharing settings. A form can accept responses from anyone with the link (no sign-in) or only from people in your organization (requires sign-in). Guest creation or admin rights are controlled separately by tenant policies.
What common network change breaks Forms?
Blocking Microsoft authentication endpoints, denying third-party cookies needed for SSO, or deploying TLS interception without trusted certificates are common causes that prevent Forms from loading or submitting responses.