This question is more complex than it may initially seem. First, you can say that Product Backlog items can include use cases, epics, user stories, even bugs, or time-boxed research tasks within the product backlog.
In the simplest definition, the Scrum Product Backlog is simply a list of all the Product Backlog Items (PBIs) that need to be completed in the project. It replaces the traditional requirements specification artifacts. PBIs reflect the needs of customers or stakeholders. A common approach to capturing end-user requirements is to write PBIs in the form of user stories.
Who is Responsible for Maintaining the Product Backlog?
The Product Owner (PO) “owns” the product backlog on behalf of stakeholders and is primarily responsible for creating it. The PO does not need to create the backlog personally—he or she can delegate to the development team and/or Scrum Master to help define and estimate backlog items. The PO is responsible for the creation and maintenance of the product backlog. Therefore, the PO also oversees the backlog refinement process.
The product backlog corresponds to your project roadmap—the plan the team intends to deliver. After the team defines it, they prioritize which features and requirements to build. The product backlog also serves as a repository containing all information the team needs to track and share.
Is a Product Backlog Item the Same as a User Story?
As mentioned, PBIs reflect the needs of customers or stakeholders. A common way to capture end-user requirements is to write PBIs in the form of user stories. However, PBIs can also include use cases, epics, user stories, bugs, or time-boxed research tasks within the product backlog. In reality, not all items in the product backlog are at the same level of detail, as shown in the image below:

Detailed Product Backlog
PBIs that we plan to work on soon should be near the top of the backlog, smaller in size, and highly detailed so they can be worked on in a short Sprint. PBIs we won’t work on for a while should be toward the bottom of the backlog—larger, less detailed. That’s fine; we’re not planning to work on these items anytime soon.
As we get closer to working on larger PBIs, such as epics, we break them down into a series of smaller, sprint-ready stories. This should be done in a timely manner. If we refine too early, we may waste time figuring out details that never get implemented. If we wait too long, we’ll block PBIs from flowing into the Sprint and slow down the team. We need to find the right balance at the right time.

Agile Prioritized Product Backlog
Who is Responsible for Refining PBIs?
The Product Owner (PO), who “owns” the product backlog on behalf of stakeholders, is primarily responsible for creating and maintaining it. The PO does not need to create every backlog item personally—he or she can involve the development team and/or Scrum Master to help define and estimate items. The PO oversees the entire backlog refinement process.
Therefore, to answer the question: the Product Owner owns the product backlog, but does not need to create every backlog item. Typically, the Product Owner may create large PBIs based on high-level requirements or user goals, then delegate to the team to help break down those large items into user stories. These smaller stories—suitable for the top of the backlog and meeting the criteria of “Ready” (usually under the Definition of Ready)—are then moved into the Sprint Backlog.