Is there any specific formate to describe a feature?

Is that feature deliverable within a Sprint timescale, to Done quality, so empiricism can be established and maintained? That's the key point to consider. Any format will suffice as long as it facilitates the necessary conversations for this to happen.

When we create a Feature, is there any specific formate to describe? What are the points we need to consider / capture when we write a feature?

Scrum does not say anything about format of features (in fact it does not use the word and the only term used is the product backlog). As Ian mentions there is no set format and the idea is to have something over which conversations should happen. The conversations should be around the business value the feature delivers, how do you split it into stories which deliver incremental value each sprint and what priority should the feature have.

What would you say if I said the "specific formate to describe" was emojis? You'd probably say I was crazy. 

The specific format is anything that clearly conveys what is needed in order to improve the Product. The points you need to capture are any that are needed to clearly convey what is needed in order to understand the need. 

I have worked with teams that were able to write some of their Product Backlog items in 1 sentence. I have also worked with some that used paragraphs to describe some of their items.  And would it surprise if I said that both of those techniques were used by the same teams?

Scrum does not prescribe or provide any format. It does not require any specific information. That is entirely up to your organization, your team to decide. 

Thanks to all for the inputs.

The above answers give all good information. As the other posts point out, there is no prescribed format, or rule around this. Determine what works in the specific context, and what gives value to the sprint. If it may help, here are two examples often used, but these are only examples. (I am keeping it deliberately brief and if need be, please get more detail from the Agile literature.)

The conventional user story approach: 
As a [type of user],
I want [some goal]
So that [some reason]
(add optional acceptance criteria)

The behavior driven approach:
Given [context]
When [event]
Then [outcome]