Non-functional requirements come in many forms, but they have one thing in common: The don't describe functional behavior of the system but rather put constraints on the design choices that you can make.
Non-functional requirements are ill suited to be expressed as user stories because user stories work best when they can be implemented once in a short timeframe (compared to the length of the entire project) and then be considered Done. After a story is Done, there should be no need to regularly revisit the story. For non-functional requirements, that doesn't work, because adherence to them needs to be maintained over the entire project. You can't say that you will look at browser compatibility only once during the project and ignore it the rest of the time.
For non-functional requirements that affect nearly all (functional) user stories, the best place to document them is as part of the Definition of Done.
For non-functional requirements that affect a relatively small subset of the functionality, you can make them part of the acceptance criteria of the relevant user stories. If this subset is still rather large for your taste (or it might grow in the future and you are afraid that you might miss some non-functional requirement on a future story), you can put the non-functional requirements in a document of some sort and reference that from the acceptance criteria of the relevant stories.
As for the format of the requirements themselves and a possible document to put them in, use whatever works best for you and your team.