All terms like "high" and "low" are relative to the level of abstraction you're working in.
High level designs something using "abstractions" -- summaries, models, etc. Some times you use UML. Some times you use powerpoint. Some times you use screen shots. Some times you use fragments of code.
Low level designs ways to implement the abstractions. Some times you use UML. Some times you use powerpoint. Some times you use screen shots. Some times you use fragments of code.
"High level" could mean anything, anything at all. You could be designing an application to run a related collection of web sites. The high level design involves big components like "Apache", "Squid", "Wackamole", "MySQL". This is sometimes called "architecture" because there isn't much new code involved.
High level could mean designing a generic web application server that could be used by multiple customers, and is built on existing technology like Apache and Django. This would involve generic libraries of reusable code components.
High level could mean designing a specific web application for serving advertising images. You might use UML. This would involve some specific use cases and a specific web server framework, but would still be high level design of modules, packages, classes and databases to provide the required use cases.
High level could mean sketching out the tables and indexes required in a database. You might use UML. Low level design could be the actual columns and data types as well as the Object-Relational Mapping.
High level could mean sketching out the classes required to support a use case. You might start with a screen sheet. Low level design could be the actual method functions to implement the classes.
High level could mean sketching out the post-conditions for a method function. You might use code fragments. Low level could mean writing the actual code of the method functions.
High level and low level are relative terms. They are relative to what abstractions you're working with.